I always wanted to read some comprehensive book on unit testing, therefore book “The Art of Unit Testing: With Examples in .Net” appeared in my list of books to read. It has been more than 1 year since I planned to read it, finally it took me only 2 days to read it – yesterday and the day before yesterday. Sometimes comprehensive things are not that comprehensive as you imagine them or… maybe with time topic is no longer that vast for you.
Nevertheless, I remember my first months of my first job as Software Developer. During one of my first team meetings question of failed Unit Tests was raised. Our clients were really concerned about quantity of tests and reasons behind tests failing during nightly builds. I clearly remember that passionate discussion and someone saying “… or are there guys who don’t know what Unit Test is?” and loud laugh after that. I made smile on my face. I maybe heard once or twice about such combination of words, resulting in abbreviation UT, but it didn’t ring a bell. I wasn’t brave enough to ask. Now I think I wasn’t one in that room who didn’t know, otherwise why would we had problems in the first place?
Because of coincidences and my eagerness, when I was about to leave many considered me as internal expert in Unit Testing. No surprises, I have many posts on UnitTesting.
Reading this book forced me to think twice about some of the testing techniques I use. Probably I changed my mind about some code I write, both in test and outside. I took some notes for myself.
Good indicator if book is for beginners is if it has something like “right click on…” – Yes, this book has few mouse clicks.
Roy introduces many definitions. Some of them are bit contradictional. For example, it might look like there are fakes, stubs and mocks while reading the book, but at some point of time you read this “A fake is a generic term that can be used to describe either a stub or a mock object (handwritten or otherwise), because they both look like the real object.” At least Martin Fowler thinks that fake is different from stub and mock. It is something I also don’t like about definitions in UnitTesting, they are blurred. Every faking mocking framework has its own interpretation and word “mock” is too much overloaded.
As per me, there are some things, which might look not completely professional for the book writer. I mean phrases like this one: “When all else fails and your code is hard to test, you have three choices: use a “super” framework like Typemock Isolator, change the design, or quit your job.” I hope you know why Typemock is highlighted as well. :)
Sometimes stuff is over explained. For example, “One test calling another breaks isolation and introduces a dependency” and then goes explanation why this is bad idea with lots of bullet points. Well, I wouldn’t even think about mentioning stupidity of doing such things.
Book “Working Effectively with Legacy Code” is referenced really often. It worth reading it. I even have hardcopy of it, but only read few pages.
Book is really easy to read. It is straight, well structured and formatted. I enjoyed reading it.
Caution: this list is my personal, for you it might look completely different.
– I tend to write extremely testable code, which often results in overengineered design with low percentage of “private” code. Roy recommends to not test methods, which are better left private to code under test.
– Stop overspecifying unit tests.
– One mock per test. I would like to violate this rule less frequently.
– Ideally one assert per test.
– Think more about applying some global testing techniques, like separation of integration tests from unit tests, or fast from slow, etc.
– Utilize more syntaxes and capabilities of testing/mocking frameworks.
Do I recommend the book?
In short, YES. If you are just starting with Unit Tests this book is excellent for your learning and I highly recommend it. If you have developers in your team who need to learn Unit Testing give them this book. Finally, read it yourself, at least scroll parts 1 and 2, read part 3 and slowly scroll part 4.