Review of The Art of Unit Testing

The Art of Unit Testing With Examples in .NET by Roy Osherove, published by Manning. ISBN: 1933988274

Introduction

The Art of Unit Testing aims to teach developers how to write maintainable, readable and trustworthy unit tests. The author Roy Osherove has recently moved over to the Ruby community but is well-known in the .NET world for his TDD courses and TDD katas. He previously worked at TypeMock as Chief Architect so he lived and breathed unit tests for a few years.

This book is not what I had expected after reading all the online reviews. It is most definitely a beginner’s book, a book for someone just starting out with TDD. The first two books I read when getting started with TDD were Working Effectively with Legacy Code by Michael Feathers and Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. The Art of Unit Testing refers heavily to them and I would describe it as an introduction to unit testing. I noticed that The Art of Unit Testing placed above them on Jurgen Appelo’s Top 100 Agile Books list and I do not understand that to be honest. It would have been the perfect text for me during the first month of beginning TDD but feels mostly redundant after reading the two afore mentioned books.

The Meat of the Book

The Art of Unit Testing is well-written and easy to read, I flew through it in a few sessions. The first three chapters are a very basic introduction to unit testing. It gets a bit more interesting after that with nice, clear explanations of stubbing and mocking in chapters 4 to 6. Chapter 6 also contains a section on creating a test API that I really liked. It is the section of the book that I am most likely to reread later. Chapter 7 goes a bit deeper into writing tests and is the most interesting part of the book. It manages to gather together most of the good tips on unit testing that I have seen before e.g. enforcing test isolation, practising DRY even in your tests, keep setup code simple, avoiding overspecification. Chapter 8 is non-technical and is about getting your organisation to start unit testing. The rest of the book lists the various unit testing tools and frameworks available as well as the classic TDD books that you should read.

The parts that could be better

The lists of tools has not dated too well. The book is written in 2009 and a lot has changed in two years. Mocking frameworks like NSubstitute and FakeItEasy are not included and Rhino Mocks gets a lot of attention. The newer BDD tools like Specflow are also not included. Those sections will be near worthless in a couple of years time.

The last chapter on working with legacy code is very skimpy for a subject that is both huge and difficult. And generally, a lot more could have been written about unit testing. Nothing about Object Mothers or Test Builders (check out this article from Los Techies or read Growing Object-Oriented Software, Guided by Tests). Not much on GUI testing with Selenium or integration testing the database or the BDD-style of testing. When I write code I do not really separate writing production code and writing unit tests, the two go hand in hand. And this makes the book less valuable than a good book on TDD even if I can understand why the author chose to do so. There are a lot of .NET developers out there who know nothing about unit testing or TDD and something like GOOS would scare off most of them.

The formatting of the code samples is dreadful, the alignment is off in almost half of them. You can still read and understand them but it feels low quality. I am reading another Manning book at the moment and its formatting is fine so I cannot understand how that got in to the final version.

And the verdict is…

I would recommend The Art of Unit Testing for anyone getting started with writing unit tests but not if you have been doing TDD for a while and have already read some of the recommended texts on TDD. It’s a nice, smooth read and very easy to absorb but it is only about unit testing and not TDD (a minus for me) and there is almost nothing about writing testable code, a huge part of testing in my opinion.

Git for Windows tip: How to copy and paste into Bash

Per default the only way to copy and paste into the Git Bash is to click on the git icon in the top left corner and select Edit->Mark/Copy/Paste. This is actually not a property of Git Bash. It is just how the Windows console runner works i.e. the standard command prompt.

There are two solutions to be able to copy/paste with the keyboard and directly with the mouse. The first is to use a different console, see Scott Hanselman’s post on Console2. I haven’t tried this yet so let me know in the comments if you use Console2 and can recommend it.

The other solution is to enable QuickEdit Mode under Options->Edit Options in the properties for the console. To open the Properties dialog, click the Git icon in the top left corner of the console and choose Properties in the menu.

msysgitPropertiesCapture

Now you can select text with the mouse and right click to copy. Pasting is done by either right clicking with the mouse or pressing the Insert key. Still more awkward than using Ctrl-C and Crtl-V so maybe it is time to check out Console2.

Git for Windows tip: Setting $HOME and the startup directory

Git for Windows opens bash in the the user profile directory per default and I wanted to change it to the directory with my Github projects instead. I had to try a couple of approaches before finding the solution.

Setting $HOME

The first approach I tried was setting the $HOME environment variable. There are a couple different ways of doing this (like messing around with the etc/profile file) but easiest for me was using Windows’ environment variables as Git for Windows/msysgit has access to them. The Home directory for msysgit is set to the Windows environment variable %USERPROFILE%  if no $HOME variable exists. So just create a $HOME environment variable in Windows (see screenshot below)  and msysgit bash will use that as the default. Now you can use the command cd $HOME to go directly to your new home directory.

EVCapture

But msysgit still opens up in my user profile directory…

Unfortunately, this does not help with the startup directory problem. The solution is actually really simple. Right-click on the msysgit shortcut and in the Start in field, enter your desired startup directory. Easy if you know how.

msysgitCapture