The costs for TDD greatly vary. Trying to do TDD for GUI / frontend programming is much more expensive. I also find TDD very hard when working within a framework that was not written using TDD.
So of course, if your environment makes TDD as cheap as ours does, I'm with you and think you have to be a little crazy to not at least try it. But it's not for everybody / everything by default.
About skipping tests for accessors and stuff: That's a slippery slope, I'm afraid it would lead me to skip more "obvious" tests which in turn make it harder to write the right test when this stuff actually is part of a bug in the future.
Agreed, my comment above was not GUI/frontend-centric and that is a different case.
To me there is another slippery slope for TDD in getting bogged down. I'm usually interested in TDD in as much as it can be a competitive advantage. The point where I feel like the returns drop off and I'm burning my man-hours and paying too much for the TDD insurance on very predictable parts is where my tests get sparser.
Keep in mind, the degree of TDD insurance I'd pay for is different for every project--for a Mars Rover you bet I'll test my accessors.
> Keep in mind, the degree of TDD insurance I'd pay for is different for every project--for a Mars Rover you bet I'll test my accessors.
Sure. If you write Mars Rover software you'll also want somebody to review your tests to make sure you didn't get the spec wrong. You can go infinitely deep here, and I'm not telling you which tradeoffs make sense for your app. I just know which ones I can live with for ours : ).
So of course, if your environment makes TDD as cheap as ours does, I'm with you and think you have to be a little crazy to not at least try it. But it's not for everybody / everything by default.
About skipping tests for accessors and stuff: That's a slippery slope, I'm afraid it would lead me to skip more "obvious" tests which in turn make it harder to write the right test when this stuff actually is part of a bug in the future.