Besides, what he says about unit testing is just WRONG. Once you know what you’re doing, it doesn’t slow you down overall.Yes, it takes longer to write the code in the first place, but this is offset by a decrease in time spent debugging, and on top of that, you get a dramatic increase in confidence in your code, a more robust design, and a reproducible, easy to run way of verifying that your code does what it’s supposed to.

The book assumes a basic familiarity with object oriented programming and design patterns (which every working developer should understand properly anyway) but it isn’t a difficult read, and it explains things very clearly.

Code samples are given in C#, but developers working with other languages will also find much in it of benefit.

Some legacy code may seem almost impossible to test, especially if it is a Big Ball of Mud with long, multi-purpose methods and no clear separation of concerns.

Then there is the question of what to do with external dependencies — components that are beyond the control of your unit tests, such as third party web services, input devices, and even the current date and time.

Ford makes appropriate parts that can be slotted and bolted into place with relative ease as replacements for the damaged originals. We’re not talking about highfalutin over-engineered Provider Singleton Visitor Adapter Mediator Repository Factory design patterns, nor are we talking about more layers of abstraction than The Princess and the Pea, we’re talking about a common sense approach to software development.

Imagine a car built the way Joel’n’Jeff seemed to be suggesting, where it was just one monolithic structure, with non-interchangeable parts. When the tyres wear thin, or the bulbs go, you have to scrap it. It’s the kind of thing that you’re either doing anyway but you just don’t know what it’s called, or else you get that kind of “aha!There are plenty of suggestions that may not have occurred to you, and you’ll end up much more aware of the “tricks of the trade.” My only disappointment was that four major, and potentially thorny, aspects of the subject — database, UI, web and thread-related testing — were only given a brief overview in the second half of Appendix B.Of course it could be argued that these were outside the scope of this book — indeed, Osherove argues that unit testing in some of these areas in particular have a relatively low return on investment — and in others, unit testing frameworks and methodologies are still very much in their infancy.He has yet another dig at Architecture Astronauts who come up to you when you’re racing to get an upgrade ready for deployment and tell you that you need to refactor your core code to use multi-apartment threaded COM. But then, he goes on to wax lyrical about Jamie Zawinski, who is, to use Joel’s words, the Pretty Boy of Software Development.He wrote Netscape Navigator in the 1990s and is Joel’s hero because—get this—he Zawinski didn’t do many unit tests. Given a leisurely development pace, that’s certainly the way to go.Unit testing is one of the programming disciplines that, to my mind at least, sets apart the reputable developers from the cowboys.