I pretty much follow TDD over 90% of the time when writing production code. I have tried not doing this, and it always results in a big mess for me that I need to clean up later, so I have learned the hard way not to skips tests. Here are a few cases where I do not follow TDD:
1.) UI Code - if it is look and feel stuff it is pretty hard to unit test this
2.) Hard To Test Code - there is a piece of code that interfaces with a external API that is not under my control. I usually refactor the hard to test code into it's own class so that I can test the rest of the code with out issues
3.) proto types - if I am just trying to hack around to figure out how to use some new API or just want to investigate something with the debugger running. Though you can also use tests to do some of this work. What I usually do after this investigation work is finished, is rewrite everything with TDD and use the prototype code as a reference as I am working.
One thing I love about doing this too, I avoid the pit fall of creating one test class for every class I have. I what i try to do is create an uber class that has everything, then as I see the need split things out into smaller classes as I am in the red, green, refactor cycle. It helps prevent coupling my tests with my code and allows me more freedom as I refactor and clean things up.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.