I'm so fed up why stupid fucks who yell to everyone "You must do TDD, because... Reasons!!!!". The fuckers even dare to call themselves " agilists" or "craftsman"...

The only reason to do TDD is to create Good Unit Tests. But by not stating the main purpose, you add a stupid process without add value.... The solution just became the problem!

So what if something goes wrong? Well, you didn't really followed TDD, because TDD never fails!!

So fuck ignorant stupid fuckers!!!!!

Having Good Unit Testing is the aim. TDD is one way to do it. Not THE WAY!!!

Also, stop using the word " coverage". It doesn't mean fuck!! If you know what kind of coverage you are completing, there could be some value...

Type Driven Development, the TDD of better language ;)

TDD 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.

TDD 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.

TDD 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...

@jotamontecino well, if every statement is hit you have taken every path, not every edge case though :)

But I agree its just one good tool, if the api is well defined TDD is both quite easy and good, but its no silver bullet.