6 ms·
Any programming language suitable for business application development is going to have static analysis tools that can reveal your percentage of test coverage.
by StevePerkins 9y ago
Any programming language suitable for business application development is going to have static analysis tools that can reveal your percentage of test coverage.
As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact.
However, TDD being hard is not a justification for not writing the test coverage at some point in the dev cycle. Too many developers, and managers, make that fallacy leap.
- eropple 9y ago> As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact. Do you care that those tests reflect the business goal or just the implementation? 'Cause TDD is way, way more likely to do the former than test-last development.
- StevePerkins 9y agoWhat are you talking about? TDD generally deals with unit testing. Which by definition is more fine-grained than end-to-end integration tests against non-mock dependencies. All of which is unrelated to UAT. Where you show the alpha to the business, and it's only after seeing it live for the first time that they start to get on the same page about what their business goals were to begin with.
- eropple 9y agoTDD totally deals with unit testing. Are your units not reflective of business goals? Mine tend very strongly to be, perhaps because I extract IO and other state crap out into the less functional part of my program (and I don't really unit test that).
- jacques_chester 9y ago> that can reveal your percentage of test coverage. Many folk only try line coverage, which loses indicative value as you approach 100%.