Testing a small static site.

Why a static site needs tests at all

It's easy to assume a site built from plain HTML, CSS, and a handful of static files doesn't need automated tests — there's no application logic to exercise. In practice, plenty can break silently: a required piece of metadata gets deleted during an edit, a security header regresses to a weaker policy, a required legal disclosure gets accidentally removed, or an asset reference points at a file that no longer exists. None of these produce a build error; they just ship quietly wrong.

The approach used here

This site's tests run with Node's built-in test runner (node --test), invoked via npm test. There's no separate testing framework dependency — the tests are plain JavaScript files that read the actual shipped files from disk (the built HTML, the _headers file, the sitemap, images) and assert against their real content using Node's built-in assert module.

Concretely, a test might read index.html as a string and assert that it still contains a specific required phrase, a specific link, or a specific class name. Another test reads the PNG social-sharing image directly and checks its actual pixel dimensions from the file's binary header, rather than trusting a filename or a comment to be accurate.

What this catches that manual review misses

• Regressions during unrelated edits. Editing the footer for one reason can accidentally remove an unrelated required link; a test that asserts the link exists catches this immediately.
• Configuration drift. A header rule that gets loosened during a later edit (for example, an accidental 'unsafe-inline' creeping into a CSP) is caught by an explicit assertion that it must never appear.
• Silent asset problems. An image resized or replaced with the wrong dimensions is caught by asserting on the actual decoded dimensions, not just the presence of a file.

What this kind of test suite does not replace

Reading a page's HTML for specific strings doesn't verify visual layout, real browser rendering, or actual accessibility behavior with assistive technology. It's a floor, not a ceiling — a fast, cheap way to prevent specific known regressions, not a substitute for manually checking new pages in a real browser, at different viewport widths, and with a keyboard alone before shipping them.

Why this fits a small team specifically

A small team doesn't have a dedicated QA function reviewing every change. Encoding the specific, previously-learned "don't break this again" rules as assertions that run on every change is a way to get some of the benefit of a QA process without needing a person dedicated to it — as long as the tests are kept current as the site's actual requirements change.