It's been my experience that the vast majority of development teams are not writing unit tests.
A unit test is code written to verify that production code is working correctly. Some of the frameworks out there that support unit testing are MSTest, NUnit, MbUnit and QUnit. A few of the toolkits that support IOC (Inversion of Control) are MEF, Ninject and Unity. Some of the toolkits that support creating mock objects are Moq, Rhino Mocks and NMock.
In addition to using a unit test framework and implementing both an IOC container and a mocking tookit, your software has to be designed and developed to be testable. Most of what's involved in building a testable system is contained in the SOLID engineering principles publicized by Robert C. Martin who's also called Uncle Bob.
A system that has not been purposely designed and developed to be testable will most likely be resistant to unit testing. So, unit testing cannot be an after thought - it has to be built into the system design from the very beginning and be part of the software development process. I would imagine that systems could be refactored to be more testable. However, this is very likely to be a slow process that may never result in high code test coverage.
On top of all these hurdles, there is another huge factor that determines whether a development team writes unit tests or not. I would say most IT decision makers don't see the value in unit testing. As a result, it's viewed as just extra overhead that only slows down software delivery. So, developers are not expected to build unit tests nor are they given the time implement them.
In order for unit testing to happen, IT decision makers have to be on board and the development team has to be able and willing to make it happen as well.
I know I've thrown around lots of ideas, engineering principles, frameworks and toolkits in this post. I plan to expand on these topics in future posts. Until then, why aren't you doing unit testing !@#?