Automated testing

Automated testing here means three separate things that get bundled under one word. Unit tests exercise a function with known input and check the output. End-to-end tests drive a real browser through a real deployment. A linter reads the code without running it and catches a category of mistake before review. They cost different amounts, catch different failures, and the useful decision is not whether to test but which of the three a given build earns.

How we use it

DMARC Engine is the build with the strongest case. Its ingest pipeline parses MIME, unzips attachments and reads XML aggregate reports from other people's mail servers, which is pure input-to-output work with adversarial inputs: exactly what unit tests in Vitest are for. On top of that, Playwright drives the signed-in dashboard, because the enforcement journey spans several pages and a change to authentication can break it without breaking a single unit test.

Jonosakti uses Jest with Testing Library over its components and API handlers, and 360nutri does the same with Vitest plus ESLint. Linked Corporate has ESLint and nothing else, deliberately. It is eight static pages exported to HTML with no backend and no forms, and a test suite there would test the framework rather than the site. Saying so is more honest than adding a snapshot test to make a badge green.

What it costs you

End-to-end tests are the expensive ones. They need a deployed environment, seeded accounts and data, browser binaries in CI, and they fail intermittently for reasons that have nothing to do with your change. A suite that cries wolf gets ignored within a month, so we keep the browser tests to the journeys that earn money or let people in, and push everything else down to unit level.

Unit tests on edge code have a specific weakness. Bindings for databases, queues and object storage get mocked or run in a local emulator, and neither is production. A green suite tells you the logic is right, not that the deployment works, which is why anything important also gets checked against a real environment after deploy.

The maintenance is the real bill. Tests are code, they rot with the schema, and a suite nobody trusts is worse than no suite because it costs time and buys nothing. Coverage percentages measure lines executed, not behaviour verified, and a README advertising a test count is not evidence of anything; we read the tests. Linter configuration is its own small tax, with ESLint's flat config migration having broken plenty of pipelines that were working fine, one of the reasons we keep an eye on dependency rot.

When we would choose something else

For data coming in from outside, we would rather spend the effort on validation at the boundary than on more unit tests behind it, which is what Zod and runtime validation buys: one schema that rejects a bad payload in production, not just in CI.

For everything that only fails under real traffic, rate limits, third-party timeouts, malformed reports from a mail server nobody warned you about, tests will not find it and observability will. On a small build with a single operator, we would fund error reporting before we funded a browser suite.