Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.
> Also, don't test stuff that isn't going to break
Hah! =) But how will I prove that i++; is actually incrementing i!
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.
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.
If the customer does not request for unit tests on the contract, usually no program manager is enforcing people to waste time writing them.
And it'll fix build times and broken tests! :)