Even 100% branch coverage doesn't mean much. While I don't subscribe to all the math in Cope's article, it's true that, theoretically, a program with high coverage can include plenty of errors.
What's interesting is that in practice, theory doesn't quite work.
2/6
What's interesting is that in practice, theory doesn't quite work.
2/6
If you TDD some little thing, making sure that every line of code you write is required by a meaningful test, and get it working, try this experiment.
Look at the code. Try to find places where a change to one or more lines will break the program but not break the tests.
3/6
Look at the code. Try to find places where a change to one or more lines will break the program but not break the tests.
3/6
I think you'll be surprised at how hard it is to find places where you can break the program and not break a test. And if you do find such a spot, ask yourself whether there is a sensible test that should have been written in the first place.
4/6
4/6
I took all those courses and learned all that theory too. And I've been writing real software for over a half century. Just as I've always found my way to the grocery store just fine, even though the traveling salesman problem is NP-complete, ...
5/6
5/6
... I've found that my TDD'd code works sooner and has far fewer defects than the code I just write and "debug".
YMMV. But if it seems interesting, maybe try it.
6/6
YMMV. But if it seems interesting, maybe try it.
6/6
