Software Engineering

Example: test the invariants, not the implementation

A practical checklist for testing a static publication: protect unpublished work, validate navigation, and inspect the generated artifact.

This is an example article showing standard Markdown, code, references, tables, and internal links. It does not claim real-world benchmark results.

Start with the artifact

A source file can look correct while the published HTML contains a broken link. Test the output readers will receive. A static build makes that output easy to inspect.

import assert from 'node:assert/strict';

const article = { draft: true, pubDate: new Date('2026-01-01') };
assert.equal(article.draft, true);

This small snippet illustrates an assertion, rather than a sufficient test suite. A useful publication test exercises the actual filtering function with drafts, future dates, and boundary times.

Protect publication boundaries

A draft must be absent from article routes, taxonomy pages, the archive, RSS, sitemap, and search. Hiding it from navigation is not sufficient.

A future date is also a publication boundary. Filtering happens when the site is built. A future article will need a fresh build after its date arrives; the static site cannot wake itself up.

Resolve relative links from their actual page location. Check fragments as well as files. Validate the generated image paths and avoid making a network request to test your own static output.

CheckWhy it matters
One main headingClear hierarchy
Canonical production originConsistent indexing
Local asset existenceReliable rendering
Custom 404Predictable recovery

Review in the browser

Automated checks should be complemented by keyboard navigation, a narrow viewport, light and dark themes, and an accessibility scan. Performance scores require measurement under stated conditions.

Read the architecture example or return to the article index.

Discussion

Comments are not enabled yet. Thank you for reading.