Testing—Not Just for Testers
There are many different kinds of testing and nearly all of them are annoying to the typical programmer. Programmers are driven to create things, build products, add features, and make things work. Testing is just the opposite. It's about finding weaknesses, exploiting edge cases, burrowing into a system, and making it break. It is a totally different mindset, which, to many people, is a good reason why programmers should not be allowed to test their own work.
“I don't understand—it worked on my machine”
—Almost every programmer at some point
But there is one kind of testing that is universally accepted as being suitable for programmers, and that is unit testing. Everyone agrees it would be a good idea if programmers did more of it, and some people think that programmers should write unit tests even before they write any functional code. Writing tests first is called test -driven development (TDD) and although it hasn't quite achieved the same degree of popular acceptance as plain old unit testing (POUT), TDD evangelists claim that it makes programmers more productive and improves code quality.
Some aspects of unit testing remain difficult—most notably, factoring out external dependencies (such as databases and networks) from unit tests without introducing an undesirable level of complexity. Adding unit tests to legacy code can be hindered by excessive coupling (where component A depends on B, C, D, E), which can make isolating a given function ...