Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
100110111144916dType Driven Development, the TDD of better language ;)
Voxera842116dTDD if done strictly should prevent all error that are use to implementation mistakes.
Bug you could still have error due to design errors as the error would be in the test already.
And covering every possible edge case with a test is many times all but impossible.
But its not a bad way to do critical parts and as you said, its also not the only way to get god testing.
And code coverage is worth exactly zero if you do not understand the problem.
Code coverage does not mean you cover all edge cases, only that you’v covered every path.
But it can still be choosing the wrong path sometimes.
But I think every one should complete at least one minor project using TDD. That way they can take all the good parts with them for when they are needed.
craig939393202216dTDD is a technique to assist other software design techniques. For me TDD is about good design, however it is not exclusive because unlike other design techniques you can practice TDD and have absolutely horrible design, or you can be so good at design the design benefits of TDD make no difference.
For me the QA part of unit testing is lesser, but still relevant.
Oktokolo116916dTDD is the el cheapo version of proven code and fails for the same reason:
You just don't have the time to do the tests (neither first nor last).
Sure, debugging may or may not cost more time in the long run, but that is time not spent right now when you have to deliver the prototype (and we all know, that the prototype goes live and there will never be time to rebuild it).
@Voxera Most of the time coverage definition is statement/code lines. Not branching, neither n-length sub-paths nor predicates, etc. The process doesn't say shit about it.
For one simple reason: TDD was thought of as ONE of the practices inside XP... Just one!
Continuous integration is as important as TDD. It helps you do small modifications and validate it still works.
Pair review also.
And it all facilitates doing simple design and validated constraints (good testing).
If you think the process IS the solution, the process will become the problem...