Back to Blog

This Static Site Has No Test Suite — Here's Why I'm Not Worried Yet

#testing#astro#static-site
This Static Site Has No Test Suite — Here's Why I'm Not Worried Yet

This repo’s CLAUDE.md says outright: “no test suite currently exists.” That’s a deliberate decision, not forgotten tech debt — though I’ll admit, if you’d asked me a year ago back when this was still Laravel, I’d have answered differently.

Why the risk is low here

This site has no complex business logic — no payments, no auth, no runtime state changing except a theme toggle that saves a preference to localStorage. Everything is static content, generated once at build time. The most likely class of bug is a frontmatter type error (a missing field, a wrong type) or a broken link, not a logic bug that needs a unit test to catch. Compare that to my old Laravel app, which had an admin panel and a generation pipeline — tests were mandatory there, because state actually changed and flows could break in ways that weren’t visible just from reading the code.

What I rely on instead

npx astro check for TypeScript validation across every .astro file, plus the Zod schema in content.config.ts, which fails the build if a blog post or portfolio item’s frontmatter doesn’t match the schema. This isn’t just theory — a few weeks ago I wrote a new post and forgot to close a quote in the tags field, and the build failed immediately in CI with an error pointing straight at the broken line. I didn’t write a test to catch that; the Zod schema did that work automatically. The effect is the same as a test — the failure surfaces before deploy — but the maintenance cost is much lower, since I’m not writing assertions one by one.

When I’d actually add tests

If this site ever grows nontrivial interactive logic — client-side search that actually filters data, a form submitting to an endpoint, anything whose state is more than “render markdown to HTML.” Until then, the cost of maintaining a test suite (writing it, running it in CI, fixing it when it’s flaky, updating it after every refactor) is bigger than the risk it prevents. I’ll be honest about this too: the reason I haven’t added tests isn’t purely a tidy risk calculation — for a project this size, the effort just doesn’t feel worth it compared to other work that actually moves the needle.

There is one gap I’m aware of and haven’t closed: nothing automatically checks for broken internal links between posts. I once found a link to a portfolio item whose slug had changed, and it went unnoticed until I clicked it manually while rereading an old post. Not a severe bug, but it’s exactly the kind of thing a simple link checker in CI could catch automatically — I haven’t built that yet, but it’s on the list of things I’ll probably get to once there are enough posts that manual spot-checking stops being realistic.

Not every project needs the same level of testing. For a one-person static site like this, type-checking and schema validation already close most of the gaps that matter. If the project were different — payments, auth, multiple people committing to the same repo — the calculation would be completely different, and I wouldn’t be saying any of this.