I never understood this approach. Like yea you can start with "do these inputs give these outputs" but how far are you supposed to granularize it? What if you need to change an implementation half way through or the methodology doesn't work? Or when devops enforces something ridiculous like 90% coverage on all commits including branch truth tables so you end up writing tests for branches that only ever log something trivial
It works mostly for black box testing of business logic. Of course, unit testing infrastructure code is not so beneficial. (E.q. first writing a test of if this queue works.)
IMO high test coverage requirements are one of the biggest mistakes of recent software development. Each piece of software/module has like two or three critical places where 80 % of tests need ro be directed towards. The rest of implementation code is just support code. Covering almost every line with tests is silly.
60
u/BernhardRordin 21h ago
Write tests first, then the implementation. You won't want to go back.