3 ms·
Brilliant article. Testing for testings sake is wrong. Testing for 100% coverage sake is wrong. Write just enough tests at the level where it catches most of yo
by astral303 15y ago
Brilliant article. Testing for testings sake is wrong. Testing for 100% coverage sake is wrong. Write just enough tests at the level where it catches most of your regressions. Drill down into unit tests for complex logic, because you can test that more extensively and much faster than an integration test. Then leave a case or two for an integration test to make sure things are hooked up right.
Don't be afraid to unit test little complex things here and there. Are you writing a function to parse a string in a certain way? Pick that function, elevate its visibility if need be, write a simple unit test to make sure you didn't make a stupid off-by-one mistake. Does the rest of the class otherwise not loan itself to unit testing? That's OK, move on.
We've learned that each line of code is a liability, even if it's a configuration file, which is why we have come to appreciate things like DRY, convention over configuration, less verbose languages, less verbose APIs. Likewise, each line of test code is a liability, so each line better justify itself.
- stcredzero 15y agoWrite just enough tests at the level where it catches most of your regressions...make sure you didn't make a stupid off-by-one mistake. One thing that I've seen in inexperienced coders (including myself in the past) is that they tend to think of every bug as a fluke one-off mistake in an otherwise mostly flawless and awesome record. New coders tend to want to just fix a bug, then pretend it didn't happen. This is exactly the wrong attitude to take. As a discipline, we programmers should be studying our mistakes and taking steps to prevent them in the future. As a craftsperson striving to improve, each of us should be studying our own mistakes and taking steps to prevent them in the future.
- astral303 15y agoI think you might be misreading what I wrote. While your points are correct, I was specifically referring to "off-by-one mistake", which is a common "silly" error (since many indices are zero-based, it's often easy to request one too many elements, or chop off the first item). Also the way you quoted me above, "make sure you didn't make a stupid off-by-one mistake" looks like it's talking about writing just enough tests. However, in context, I'm actually referring to writing unit tests for small items where you might make a stupid off-by-one mistake. So I was never referring to "one-off mistakes", as in mistakes that are flukes. Your points are all good otherwise! Never rest on your laurels and always think about what you can do to catch your mistakes.
- stcredzero 15y agoI did misread what you wrote, but I thought the point was a good one to make, so posted it anyhow. Not disagreeing, just adding.
- Pheter 15y agoIt seems so obvious to me now, but I just realised that is something that I do; I focusing on understanding what is causing a bug and how to fix it, but not why the bug occurred in the first place and how to prevent myself making similar mistakes in the future! Thank you so much for making me aware of this.