On Testing
Testing was never meant to be a chore. Testing was never meant to be a necessary evil invented by some neckbeard at IBM in the 80s. It was also never meant to be a burden to developers.
With more code potentially being written by AI agents, testing has never been more important. More contributors working autonomously means there’s even more need to verify the code they’ve output beyond a simple code review.
Good tests are meant to shift the burden of proof. It’s really simple, when someone with an unearned sense of confidence says your software doesn’t work, you call bullshit and say, “It totally does, and I can prove it empirically.” It’s up to you how combative you want to be in response. YMMV.
Run your tests. Show the outputs to stakeholders. I will never forget running a bunch of tests with Playwright in a sprint demo and hearing the product owners lose their corporate minds over it.
But tests need to be valuable to be worth your time and tests are most valuable when:
- They show the limitations, risk and resistance of a piece of code to changes, refactors and unknown inputs.
- They lower the culpability of engineers and shift the burden of proof off to another party
- They can present a legible indication of the health of a codebase and the broader system
- They’re a source of documentation for how an API is being used appropriately
(Side note, any unit test for React that just shows a component rendered is entirely useless, it’s just meant to deceive your coverage tools. But writing good unit tests in React is a whole other topic in and of itself.)
This applies to tests all down the stack: Unit tests, smoke tests, integration tests, E2E tests, acceptance tests — whatever tests your team feels like writing. But write tests, write lots of tests, integration tests, unit tests, edge cases, and make them worth your time.