Jacob Proffitt has a two posts here and here on how the emphasis on TDD instead of plain unit testing is harming the adoption of unit testing.
His basic assumption (if I understood him correctly) is that people would adopt unit testing faster if unit testing proponents told them doing it without TDD is an option too.
This sounds logical if it were indeed easy to unit test without TDD. I think it's not
I found this out the hard way. Not because the testing is hard but because the code I (and some of my coworkers) used to write was highly test-resistant. I almost stopped unit testing because it took too much time to do and it took too much time to maintain the tests. The problem was that there were too much dependencies between parts of my code. Tests would be hard to write because I had to write a lot of setup code. And existing tests would fail all the time when seemingly unrelated parts of the system changed.
The solution has been well known for decades. You have to reduce coupling and increase cohesion in your code. I knew this but this is hard to maintain without immediate feedback on the quality of your code. That's where TDD comes in. By writing tests before you write code you get feedback on the testability of your code before you've written a single line of it. You're forced to think about how to call the code before it's written.
I know that I'm making an implicit assumption here too. I'm saying that testable code = high quality code. But my experience tells me this is indeed true.
If someone were to ask me how to start unit testing. I'd tell him to start using test-first on new code. Usually domain logic is easy to decouple so it's easy to test. Testing code that has been written code-first is advanced unit-testing and it's the easiest way to have people who are new to unit-testing stop doing it forever.