4 ms·
I’ve worked on countless codebases with thousands of unit tests, integration tests, synthetic tests, automated acceptance tests, automated UI tests, etc. The o
by GiorgioG 3y ago
I’ve worked on countless codebases with thousands of unit tests, integration tests, synthetic tests, automated acceptance tests, automated UI tests, etc.
The only real “test” is whether it works in production. Everything else is a poor substitute and gives you false confidence. It’s absurd the amount of time and effort we spend on writing tests and we still have as many, if not more bugs in our software than we did before writing tests became a religion.
- magicalhippo 3y ago> The only real “test” is whether it works in production. Everything else is a poor substitute and gives you false confidence. Tests are like bloom filters[1], either they fail and you have a bug (either in code or in the test itself), or they pass and you possibly still have bugs. As such they only give you false confidence if you're overly naive. If our tests pass then we know what we know. Doesn't mean we pretend there can't be unknown unknowns, so we still need diligence before rolling out a new version into production. [1]: https://en.wikipedia.org/wiki/Bloom_filter https://en.wikipedia.org/wiki/Bloom_filter
- simonw 3y agoIf tests are naming you less rather than more productive, you should rethink how you use tests. (I've seen MANY examples of unproductive tests, they're definitely a very real problem - but it doesn't have to be that way.)