I have seen this happen a few times in the last couple of months when new developers have been introduced to TDD.
Initially, enthusiasm is high at trying something new but after a few short days these guys can dismiss it out-of-hand because 'it doesn't work'. They find that writing tests for their code is difficult so conclude the technique is flawed.
In 99.9 cases out of 100 this is because these guys have missed the point - TDD is about using the process to help you design and produce a testable code base by creating tests first to help shape your design and make it testable.
My experience has taught me that you can usually create the tests you need quickly and simply - if the tests are complicated and taking a long time it's a pretty good indicator that you are heading in the wrong direction.
A point in fact is logging - loadsa folks love to have a logging manager which is either (1) a singleton and then they spatter their code with Logger.Instance.Log() calls or (2) a static constructor of Logger logger = new Logger(blah, blah).
I have no objection to singletons per-se but this is a clear example of tightly coupling classes together because you can't have an instance of your class without requiring a Logger to be setup and configured - this could be considered fine for production but a real pain in the @ss for testing! If the test had been written first the coder would quickly have realised that this is a bad idea since they would have to produce code to setup and configure a logger before doing anything else and then do all the required housekeeping to tidy up after it when the test is complete. Add to that the possibility that the logger may have bugs which could cause false negatives in the tests and you know you're already in trouble...
If you have an ILogger interface and allow an instance implementing ILogger to be supplied to your class all this hassle goes away - you can instantiate your production class in the test fixture and just squirt in an interface mock of ILogger using TypeMock, NMock, RhinoMock or any other mocking gizmo you care to try. (For any typemockers out there - I know TypeMock supports MockAll which can intercept calls to singletons but it still leaves you with tightly-coupled code).
This can be compatible with singletons too - if your singleton implements ILogger that is. Logger.Instance could be supplied to your class in production just as easily as an interface mock or any other ILogger implementation for that matter == loose coupling == more flexible code which can be re-used.
TDD is a design process in my book and takes commitment, practice and discipline.
It's tempting to switch off a few problematic tests when the deadlines are tight - but how can you be confident that there are no breaking changes (and why bother in the first place)?
It's not something you just sit down and do straight off the bat - you need to practice and you will get better and faster. You will spot pitfalls and avoid mistakes - you will also find yourself adopting testable tried-and-tested (no pun intended) design patterns instead of re-inventing the wheel every 3 weeks.
It's very easy to find yourself writing code and saying "I'll implement a test for that in 5 minutes" - so you bung a MyMethodTest(){} in your test fixture with an [Ignore("")] attribute for the time being with all the best intentions of going back to it. NUnit gui is littered with yellow blobs with no explanation of why - I have fallen into this myself in the past and those few tests I needed to write in a few minutes added up to a weekend's work that I would much rather have spent on Bournemouth beach! A lesson hard learned....
Now I've got that off my chest I think I will have a nice cup of Columbia's finest...