It looks to me like another blog posting by a TDD evangelist, most of which I ignore because he ain't preaching my religion. He did, however, touch on what the

It looks to me like another blog posting by a TDD evangelist, most of which I ignore because he ain't preaching my religion. He did, however, touch on what the important part of the pragmatic vs dogmatic question. This jumped out at me: > In general I don't write tests for any code that I have to "fiddle" into place by trial and error. It is congruent with a some general rules I follow to decide if I should write a test for something: 1) Do I care if this code doesn't work on the non happy-path? Maybe I'm writing some isolated prototype code that will probably be thrown away, or perhaps I'm planning to rewrite it later. I'm not going to bother writing tests. 2) How important is it that this code is bug free, and how soon should there's a bug. If, say, the code is in a highly used part of the program that is required by the rest of the app to function properly. Or it is part of the main feature set. I definitely will write tests. 3) I'm under time constraints. If I don't have the time to write tests for a particular part of the code, then I don't have time. 4) How solid is the architecture/interfaces? If I expect them to change quite a bit, then I will not write so many tests, or perhaps any. I once worked on a project that was heavy into unit testing/tdd. There was hundreds of tests written very early on in the project, and since the code was changing so much, we spent a lot of time re-writing tests. It eventually got to be a huge time sink. 5) How much money does the project have? Writing lots of tests takes time, and time is money. I've worked on some projects that have budge (or time) constraints, so I don't have the luxury of such dogma. All that said, I often dislike programming religions or dogma, because they often advocate following a practice somewhat blindly, without understanding when the rules/precepts should be applied.