4 ms·

I have somewhat the same experience with my first real TDD-based project. Progress was slow, but the amount of debugging afterwards as almost zero. It feels slo

by roeles 5y ago

I have somewhat the same experience with my first real TDD-based project. Progress was slow, but the amount of debugging afterwards as almost zero. It feels slower, but more predictable. > Recently decided on using TDD for some library code and aiming for >90% test coverage at my dayjob. I thought the point of TDD was that you don't write code unless a test requires it? In my mind (and the little experience I have) that translates to 100% coverage, with exceptions of really annoying side-effects that are near-impossible to test reliably.

KronisLV 5y ago
> In my mind (and the little experience I have) that translates to 100% coverage, with exceptions of really annoying side-effects that are near-impossible to test reliably. Yep, like Java supposedly being cross platform, but having different file system implementations, because using one implementation across multiple file systems just isn't entirely feasible, for example, due to how paths are validated. Thus, no matter what i did, i couldn't get the coverage to 100% due to semantics of how i'm supposed to validate that the low level call works and because i have branches in the test, one that checks whether the correct exception is thrown in Windows and a different exception for Linux. Even if technically the code paths are covered, telling that to a subpar code coverage plugin is hard. So, i just settled on writing code for everything myself, but having 90% coverage be enforced on a class line level to account for the weirdness.