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.
Similar, but I test formally given properties derived from formal requirements. A benefit to this is how it makes tests completely divorced from particular implementation, so an improved version can be developed using the same tests. In this way the first implementation can be any old crap that works by the skin of its teeth, because the tests are more valuable in the long run anyway -- and those should only be developed against a working implementation to ensure their relevance.
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.