[anthonyb]

You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code.

Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.

[jasonlotito]

People always ignore the refactoring. They also look at the time TDD adds merely in terms of individual sessions. They don't look at the project as a whole.

> Also, don't test stuff that isn't going to break

Hah! =) But how will I prove that i++; is actually incrementing i!

[anthonyb]

Well, if the incrementing is part of a method somewhere, it probably should be tested, but as part of testing the method, not the ++ itself.

Usually it's more like people testing the basic mechanisms of frameworks or libraries. In some cases it makes sense, eg. if a library that you're depending on is a bit dodgy, but usually it's just a waste of time.

[taligent]

The problem is that that right now in the software industry:

TDD, Agile, Scrum, XP etc are a religion.

And a lot of people have managed to make their lives easier by making the teachings of this religion mandatory. So what I've been witnessing the last few years is that saying "no I don't think we need a test for this" is a position that will get you no where. So instead every one just puts up with longer and longer build times and spending more time each day fixing broken tests.

[anthonyb]

That's an overly cynical take - I've seen both TDD, Agile and Scrum work really well. In any case, refactoring is part of the religion too, so it shouldn't be too hard a sell for you.

And it'll fix build times and broken tests! :)

[pjmlp]

Come work to the enterprise world where no one cares about whatever the cool kids are proposing.

If the customer does not request for unit tests on the contract, usually no program manager is enforcing people to waste time writing them.