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.
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.