DEV Community

Discussion on: How to write good software tests

Collapse
squidbe profile image
squidbe • Edited on

If you’re testing 2+2=4 and it’s not failed in the last 25 years, then it doesn’t tell you anything when it passes.

While that's obviously a rhetorical example, your point is valid. I've seen way too many tests that are testing obvious things that wouldn't fail or things that would be caught simply by linting. The problem is that some managers/teams focus on code coverage and simply think "higher is better". Engineers should consider whether a test is testing something that can break under certain conditions (e.g., unexpected input) or if certain conditions aren't met (e.g., a data contract changes).