2 ms·
The funny thing about unit tests is that it's actually possible to write unit tests that don't really help you at all and that this is the way how many unit tes
by erikb 10y ago
The funny thing about unit tests is that it's actually possible to write unit tests that don't really help you at all and that this is the way how many unit tests are written (a pessimistic me would say "most"), but nobody thought that would be possible.
The initial people who came up with the idea thought about writing down the execution of a usecase, or a small part of that, as a test. Then they ran their code against it while developing it. That gave them insight into the the usecase as well as the API and the implementation. This insight could then be used to improve tests, API and implementation.
But most professionals aren't about making quality. They are about paying their rent. So when they started to learn unit tests, they just wrote their code as always, and then tried to write tests, no matter how weird or unreasonable, to increas the line coverage of their test suite. The proudest result for them is not to have a much more elegant implementation, but to find the weird test logic that moved them from 90% coverage to 91%.
I believe that's how you get a lot of clutter in your unit tests. However what is described in the document are sometimes example of people really trying, but that are just early in their development. Of course when you learn to do something by a new method you will first do crappy, inefficient stuff. The idea here is how much do you listen to feedback. If that team that broke their logic to get higher coverage learned that this was bad, then they probably adapted after some time, and then they did exactly what unit tests are there for.
- sametmax 10y agoYes, I was the bit of a shock the first time I realized how misleading coverage was. Being executed doesn't mean tested. Tested doesn't mean it works. Working doesn't mean it does what you want. Doing what you want doesn't mean it will do what the client wants. Doing what's the client want now doens't mean it will do keep doing it in the future. But anybody who edited a 100 000 lines long project, ran the unit test, and saw red lines, fixed them, ran it again and then saw green now the feeling : it's great. You are way more confident.
- madgar 10y ago> But anybody who edited a 100 000 lines long project, ran the unit test, and saw red lines, fixed them, ran it again and then saw green now the feeling : it's great. You are way more confident. This is the key insight: unit tests are about feelings more than anything else. People get so defensive in unit testing threads because eliminating unit tests means eliminating their source of confidence.
- ma2rten 10y agoIt depends. In a language like Python having 100% test coverage is in and by itself beneficial. A unit test prevents the kind of problems what would be caught by the compiler in a compiled language.
- ploxiln 10y agostatic-analysis tools, like pyflakes, can also find some of those things (semi-obvious problems like variable name typos that would remain undetected until that actual line was executed)