Five Ironies of Unit Testing

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/five_ironies_of_unit_testing.htm]

I am a huge advocate of unit testing. After years of writing tests, and encouraging other devs to write tests, I find five common ironies:

1. The devs who would most benefit from unit tests are the devs who are least likely to write them - and vice versa. The star devs, who would write the code correctly to begin with, are also the ones most open to unit testing. Likewise, the low-quality-code-developers who shun testing are the one's whose code could benefit the most from it.
2. Writing unit tests actually saves time - not just in integration testing but also in development - because it stubs out the context, allowing you to immediately jump to the area that needs testing instead of spending 5 minutes setting up the scenario.
3. Developers often punt on unit testing because "my manager doesn't support it", but unit testing is really an encapsulated development detail that doesn't need managerial support (although of course their support is appreciated).
4. Many devs generate the unit tests after they write the code ("those ivory-tower architects said we needed tests"), but tests are most beneficial before you write the code because they force you to think what the code does, and they make it faster to write the code.
5. The same teams who don't want to write unit tests are relieved to have such tests on the code they need to maintain.