I used to think "If all tests pass, it's perfect, right?" but when I really thought about it, I realized that might not be quite accurate 😳💭
Recently, while writing some "perfectly passing tests," I had a sudden realization. Tests don't actually prove that code is correct - they just show that different pieces of code 'agree' on how things should work ✨
To put it in a common example:
- The implemented code thinks "this is how it should work"
- The written tests also think "this is how it should work"
But what if that "this is how it should work" is based on wrong assumptions?
All tests would pass, but the actual behavior could still be weird... this happens more often than you'd think 🥺
In other words, even if all tests show green checkmarks, you might just be holding false confidence.
Isn't that kind of scary? 😱
So I've been trying to shift my perspective lately.
Maybe tests aren't about "proving correctness," but rather about solidifying the intention of "this is how it should work".
They're like markers saying "Hey, if you change this behavior, let me know!" ✨
But here's the tricky part - sometimes that "intention" itself is wrong.
So even if you write tests, blindly trusting them can be dangerous... 🤔
I'm still figuring out the meaning and usage of tests while writing them,
but what do you all think?
Are tests "proof of code correctness"? Or "specification documentation"? Or maybe "guardrails against chaos"? 🛤️💡
If anyone has better ways to work with tests, I'd love to hear them! ✨
Hatena
Comments
リリー
"Program testing can be used to show the presence of bugs, but never to show their absence" - Dijkstra
ハンナ
Even if it works according to requirements, if the requirements are wrong, it's not the code or developer's fault.
キンバリー
I think of tests as defining expectations of "this is how it should work" and creating a mechanism to immediately know when those expectations are broken.
ミア
Passing tests don't necessarily mean it's correct, and failing tests don't necessarily mean it's absolutely wrong. They're feedback telling you when expectations have changed.
クリス
That's why integration tests and acceptance tests are most important. When you evaluate from the customer's perspective, if the requirements are correct, you can tell it's working properly.
ロバート
Good tests aren't constraints - they're like guardrails that guide you in the right direction.
ジョージ
"Proof that code works as expected" is different. Tests prove whether it works as you think it should, or whether it meets requirements.
サム
The key point is "you." Are you having AI write your tests?
グレース
Fixing intentions isn't just for yourself - it's to make them understandable to other developers too. They're there to protect requirements.
サラ
Tests confirm requirements and help everyone understand how to use and how complex systems behave. When touching new codebases, I first run tests to check, but if the tests are bad, I get anxious about proceeding.
マックス
Documentation isn't verification, and it often becomes outdated the moment it's completed.
リリー
Tests also serve to protect against future changes breaking requirements, and to verify that the system behaves as described in the documentation.
クロエ
Also, similar to the saying "a bug that isn't fixed becomes a feature" - if a bug remains for a long time and gets depended on, you need to maintain backward compatibility, so you should consider writing tests for that buggy behavior.
ハンナ
You shouldn't leave always-failing tests unattended, and bugs that aren't fixed might not really be bugs.
ロバート
This is a long post about how tests should be written according to requirements.
グレース
Looking at tests as one big category doesn't make sense. There are various purposes: logical operation verification, project requirement compliance, internal requirement compliance, code path coverage, regression detection, etc. Expecting one test to cover everything is wrong.
キンバリー
Also, learning TDD where you write failing tests first would be good. I don't do it much now because it's tedious, but confirming that tests fail is an important mindset that makes you think about what you're actually verifying.
マックス
This statement is true, but you could also say it doesn't mean much.
リリー
But tests aren't meaningless. It's like how you can't test all economics knowledge in every aspect of life, but within economics itself, it's sufficient.
エイダン
OP has only one AI-generated post promoting a blog.
レオ
When fixing a bug causes many tests to fail, it's because the tests were written that way.
ハンナ
Tests should only check what's truly necessary and exist to verify that important parts aren't broken by changes, but with the stupid idea of "needing 99.9% coverage," people wastefully test every line too much, requiring massive test fixes just to fix one bug.
サム
How am I supposed to believe my changes are correct when I have to fix so many tests?
ロバート
Tests fix functionality, its assumptions, and requirements.
ミア
If a new developer breaks something later, tests will warn you first.
グレース
But if the new developer also changes the tests and gets it through review, there's a fundamental team problem. Tests are just a small part of that.
クリス
The purpose of tests isn't perfect proofs like those created by John Carmack or Donald Knuth, but more like alarms that tell you when someone breaks requirements during new feature development.
サム
If reviews are bad, there's no integration testing, and QA just clicks buttons, tests won't help.
エマ
But having no tests is way worse. I've experienced it - it's hell...
ハンナ
I really hate code coverage requirements. When PR reviews are sloppy, tests often become meaningless things just for coverage points.
キンバリー
Whether tests are useful depends on:
キンバリー
1. Writing tests first according to requirements (TDD) prevents your code and assumptions from just being self-affirming.
キンバリー
2. Tools like cucumber and gherkin were created so business people can write and see tests. This connects tests with business requirements.
キンバリー
That's why you write tests first. Tests define the functionality, and passing them means implementation is complete. When you can't think of any more failing tests, it's done.
ロバート
After that, tests catch changes that break the specifications.
