How to write tests for a Hugo website?

I was looking for ways to write some tests (as part of CI/CD) before my Hugo site is deployed to production. So far I have found one way of testing, which is by running hugo on my codebase as part of CI/CD. If the command fails then I know that, something is wrong.

So I have two questions to ask:

  1. How do I run tests to check Hugo templating & syntax ?
  2. How do I run tests on the final build (the static HTML output) ?
  3. How to run tests on data files (YAML/TOML/JSON) and content files (Markdown) if any ?

Regarding the second question, I have another basic doubt. Does it make sense to write tests for static sites built with Hugo ? Given the fact that, we will not be dealing with input elements like text input, checkbox, radio button etc. (in most of the cases).

Please share your views/ideas regarding this.

To visually or markup-wise test a website (that might or might not have been created by Hugo) you use a tool that employs Puppeteer or Playwright, which both are basically autopilots for your browsers. Libraries that do this are Nightwatch.js and Cypress. To test TOML/YAML/JSON you take any arbitrary linter that will tell you if the format is followed. To test values of TOML/YAML/JSON you build a test-case layout that prints what you are looking for and then use one of the tools above to see if what you expect is there or not.

Selenium is the grandfather of “testing in a browser session”. Not sure if that changed, but some years back it was powerful, but slow, hard to configure, a pain to use, but the only one available.

Here is a little overview (never heard of testcafe):

In my opinion:

  • Cypress before Nightwatch if you want to script your tests.
  • Playwright before Puppeteer, because the first one supports multiple browsers, not just chrome.

All of them could theoretically check your running hugo server too.

1 Like

I think that things like HTML validation can still be useful for two reasons:

  1. When you are creating layouts it’s easy to create non-compliant or a least somewhat questionable HTML. Validation makes sure you catch that.
  2. I’ve managed to have situations where content, in combination with the layout, has created invalid HTML, but it takes particular content to trigger the issue.

I don’t know if you have seen the audit for Hugo that Joe Mooring has created, or my scripting of same:

For the majority of the tests I’d suggest that they are off-top as not being Hugo-specific or being more about what providers you use (e.g. GitHub actions, whatever GitLab uses, Netlify stuff, etc).