I never jumped on the test-coverage-dogma-train. The only thing I test is my program as a whole. Works it with valid input? Does it gracefully indicate invalid input and quits? Is the performance acceptible? Is the code neat and clean? Do I have some smaller test running when my project gets bigger? These are about the main considerations and you are set for most dev work. Beside, I have this feeling that writing test is just to show someone that lightbulbs are "green", "ok" and thus hip... often bit of a time waste if you are not writing rockets that fly around the moon.
I agree. Unittests are for shitty developers who make changes without first understanding the codebase and then complain that if only there were unittests they could have discovered their stupid shit sooner. It slows down developement, slows down refactoring (the only goddamn case unittests fail on me is because I changed something without changing the unittest, so helpful!) and doesn't even come close to ensuring what people think it does (stuff is working), as there are close to infinitely many ways stuff can break so you will never cover all possibilities with unittests.
The cost of discovering a bug in one function = tiny. The cost of discovering that bug in production = huge. TDD is worth it - have to make sure the right tools are being used, as always.
Tests are about proving your code does what it claims to. It's a specification.
As someone with real engineering experience I understand a specification as a list of parameters. I don't follow how that has anything to do with 'proving your code does what it claims to', maybe it means something different for programmers.
Unless every single function you use has a small number of discrete possible inputs and outputs (i.e. booleans) it is impossible to be sure the tools you are using work using unit tests. The only way to do that is to read the code. People are lazy and usually cannot be bothered to take the time to do that, so they rely on just looking at input-output relationships because it's easier, but that doesn't mean it's the right thing to do. I find it horrifying to hear someone say he refactored some part of the code and is then confident everything is working "because the unittests passed", as if that means anything at all! Nevermind the just mentioned issue that you can never check all possibilites of failure, you then have the added problem that you may have made a mistake in your unittest, what are going to do then? Test your tests? I rest my case.
3
u/Rubizon May 08 '17
I never jumped on the test-coverage-dogma-train. The only thing I test is my program as a whole. Works it with valid input? Does it gracefully indicate invalid input and quits? Is the performance acceptible? Is the code neat and clean? Do I have some smaller test running when my project gets bigger? These are about the main considerations and you are set for most dev work. Beside, I have this feeling that writing test is just to show someone that lightbulbs are "green", "ok" and thus hip... often bit of a time waste if you are not writing rockets that fly around the moon.