Customer Reviews

The Art of Unit Testing: With Examples in .Net

5 star:		(28)
4 star:		(7)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

This book covers unit testing in .NET from a pragmatic, yet thourough and passionate, perspective. In brief, it covers many important dimensions of unit testing from simple "hello world" tests over the use of Stubs and Mocks to how you write maintainable test code. It also covers organizational topics such as how you introduce unit testing in an organization and how to do code reviews of tests.

Although unit testing has become somewhat synonymous with Agile practices, such as Test-Driven Development (TDD), the book never assumes that you will be using TDD. It is valuable wether you write your tests before or after your code.

Roy Osherove clearly has a lot of experience with unit testing, and he willingly shares so we can learn from his mistakes and successes. As a long-term practitioner of TDD myself, I can vouch for most of the advice imparted by this book: It is based on established patterns and best practices that the unit testing community have arrived at through years of experimentation.

Being the anal-retentive perfectionist that I am, I would have liked to see the book adopt the Pattern Language of xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series), but at least the guidance of those two books are very much in harmony, even if the terminology differs.

In summary, you can say that this book is a very readable and useful introduction to unit testing. If you are a beginner to intermediate unit test developer, you should definitely read this book - and then, as you become more advanced, you should still read xUnit Test Patterns :)

This book is not an evolutionary book to other unit testing books out there; it's revolutionary.

First of all it's not a thinly disguised book trying to sell you on TDD (as some unit testing books that I've read are), but rather it's a book that truly lives up to it's title - the art of unit testing.

Secondly, the discussions and examples in the book take real world considerations in mind. These are not simple contrite 'Hello World' tests, or 'perfect world' sets of code. It discuss' writing tests on both green and brown field applications.

A third aspect that is truly helpful is that there is an entire section for dealing with implementing unit testing in an organization and the politics you might face while doing so. Because the book isn't biased towards a particular software discipline, tool, or language, but on the 'art' of unit testing, these are tips and tricks you can take with you anywhere.

If you found books like 'The Pragmatic Programmer' or 'The Inmates are Running the Asylum' getting you revved up to write better software, then this book will drive you to a whole new level of unit testing.

I've been doing unit testing for several years now, but it wasn't until after I read this book, that it no longer was a chore that I checked off my 'TODO' list.

The Art of Unit Testing: with Examples in .NET

In short, if you want a tactical book on unit testing that distills the passion and love of an expert practitioner into a very readable yet reference-friendly text on unit testing, this is it.

If you are new to unit testing or TDD, this book will demystify the practices, tools and techniques that would otherwise take years and lots of frustration to get right.

If you are an experienced practitioner of unit testing and TDD, and are already practicing SOLID, TOOD, and BDD not just as a flavor of the week but as a way of life, this book will provide unambiguous insight into different approaches that will help you refine your existing techniques or at a minimum, validate your approach which is always valuable to any developer who has an opportunity to review his/her techniques with a seasoned master. This book will afford you that opportunity.

While the book cites excellent references for TDD and design patterns, if there is one thing that I thought was missing was a narrative- even if by way of an appendix- that ties all of the techniques covered together in an example of building the example Logger component using TDD. I understand that this book is not about TDD, but at the same time, that's like a book on scuba equipment that teaches you precisely how to pressurize your CO2 tank, keep your mask from fogging up and care and maintenance of your scuba suit not being about scuba diving.

That said, knowing Roy, it must have been painful to resist a detailed examination on TDD, but, for this book to be effective, it had to be relatively short, to the point and most of all pragmatic for it to succeed at filling the void on the topic of unit testing techniques and practices. To that end, Roy hits the mark very elegantly without being pretentious, catering to those who test first, test last or don't (yet) test at all. While I would love for everyone to pick this book up and start doing TDD today, even if you aren't yet convinced on TDD, applying these techniques to writing code that is testable, and learning how to test the right things will be an instant asset to your product, your team and your organization.

Ok yes i didn't rate it at 5 stars but i think its definitely a book everyone should have on their shelf. A lot of books i read go up for sale after i'm done this won't happen to this book. Its a keeper. Don't kid yourself. Unit testing is hard especially if your working on a system that wasn't designed / architected for unit testing. This book allowed me to "start" implementing unit testing in our internal app that i thought in the past would be impossible to add unit test to. Roy does a lot show you how to break down a system (dependencies mainly) to be able to unit test it. He has great standards to start from (naming, construction, ect...). He also adds enough info about TDD (Test-Driven Development) to show the advantages but doesn't turn into a testing zealot.

That being said the book isn't perfect (reason for 4 instead of 5 stars). First he talks very briefly in the early chapters (forgot which one) about Inversion of Control containers (IOC). He talks about IOC somewhere around where he is talking about constructor injection. He then goes on to say that IOC are beyond the scope of the book. I definitely disagree with this and think a good amount of space in the book (maybe a chapter or part of a chapter) should have been taken discussing the principles of IOC and where/why/how to use it. Its an integral part of constructor injection. If its beyond the scope of a unit testing book then where does it belong? IOC is beyond the scope of the book yet a discussion on a productivity tool (resharper) is (which i have to say i didn't mind because i found it interesting)? I just think this is a big omission in this book and is the main reason for the (-1 star) and not my 2nd point i'm about to make.

Ok the 2nd thing is the author works for TypeMock. He finally tells you that in later chapters. He seems to push Typemock a wee to much i think. Yes TypeMock is definitely the best mocking framework out there. It will allow you to mock things that you generally couldn't mock with other frameworks (Static/Shared methods) but after looking at the cost its more than a little expensive. It would have helped us greatly but the licensing cost are unreasonable (especially when you compare it to the other frameworks...FREE). Anyways, back to the topic at hand. I think the author seems to push it a little to much in the book though i will have to give it to him for using RhinoMock (free) for almost all his examples in the book.

I thoroughly enjoyed reading the Art of Unit Testing. My only knock against the book would be chapter six, which was a bit dry and perhaps not as unambiguous as it could have been. Nevertheless, the content of the book is phenomenal. Whether someone is experienced with unit testing, or is just starting, this book is invaluable.

As I type this the things that stand out about the book are as follows:

1) A clear description of what a unit test is, as well as what it's not and how it differs from integration testing. This is important because if one isn't careful, a unit test can easily turn into an integration test.

2) Why unit testing is important and useful.

3) The differences between stubs and mocks, as well as when to use them.

4) How to create trustworthy, maintainable, and readable tests. I think this is the most important section of the book, outside of perhaps the basics about unit testing and isolation frameworks. It's obvious that if unit tests become a pain point or add friction to a developer's job, then any success or benefit from them will be limited. If one invests the time and effort to create the tests, then they should be able to get the most return out of that investment.

5) A good introduction to a variety of frameworks and techniques useful for not just unit testing, but also in facilitating good design in general.

6) Addresses the political issues involved with introducing unit testing to an organization.

Roy Osherove provides many heuristics and opinions in his book. I don't necessarily agree with all his viewpoints, but the majority of them I've found very helpful and insightful. This book also contains many gems that I will remember and refer to often. One very astute gem is as follows: "There is no object-oriented problem that cannot be solved by adding a layer of indirection, except, of course, too many layers of indirection." Adding unit tests to an application can indeed result in creating additional layers of indirection. Sometimes these layers can feel awkward or unnatural.

Thus, knowing how to make best use of unit tests is as the title suggests part art. I know this book has improved my skills at unit testing, and I highly recommend it to anyone wishing to do the same.

Osherove covers new ground in this brief, dense book: unit testing. Although unit testing has become something of an article of faith among the Xtremists and in many industrial settings, the only way to learn it has been under the guidance of an experienced tester. (I recently had a shocking experience with an undergraduate class. Apparently, testing had never come up in their four years, and some didn't even know that a test should distinguish correct from incorrect behavior.) This isn't really a formal program of study, but it's the best how-to I've seen to date.

The author covers the topic at many levels. For the beginner, he presents the fundamentals like what a unit test is and even why unit testing is a good thing - which, believe it or not, some people still argue against. He shows how unit testing interacts with other parts of the design cycle, such as refactoring. Among other things, testing a module in isolation requires that the code be isolated, that its dependencies be clearly identified and be amenable to replacement by test fixtures. I didn't see Osherove state this outright, but one benefit of the unit test lifestyle is that test-friendly code has fewer dependencies and more explicit ones - something that makes maintenance enormously easier, or even possible in some cases.

Large parts of this book refer to specifics of the .NET environment or of specific tools, of which dozens seem to exist. Even if you don't use those tools or that environment, there are still important lessons in these sections, since concepts are often transferable even if particulars aren't. He adds new meaning to common knowledge, too. For example, he defends some cases of redundant tests written by different people, on the grounds that they're likely to test different things. This puts new words to the "N-version programming" concept familiar in the fault-tolerance world. There, the hope is that different implementations will contain different defects; here, the observation is that different implementations often detect different defects.

Of course, I found a few things to disagree with. Osherove makes little mention of randomized testing, something that I often find useful - directed tests cover the cases I was thinking about, but randomized testing often reveals cases I wasn't thinking about. And, although I generally agree with his premise that tests themselves shouldn't contribute to the debug burden, I find that looping over data elements that specify test cases can decrease global test complexity at some cost in local complexity.

Beginners shouldn't expect to understand everything that Osherove presents. Likewise, experienced testers should be patient with the introductory material that leads up to the advanced discussion. All of this book will have value to one reader or another, but any one reader might not find all of it useful. Also, unit test tools are still maturing, so discussing the many tools available makes parts of this book seem scattered. Still, if you don't have a test guru to study with (or even if you do), I strongly recommend this book.

-- wiredweird

This book is a good introduction to unit testing. It is clearly written and covers the subject well. Osherove also references several other books that the reader will find helpful including Code Complete: A Practical Handbook of Software Construction and The Pragmatic Programmer: From Journeyman to Master that should already be on your shelf. The other two books that come up several times are xUnit Test Patterns: Refactoring Test Code and Working Effectively with Legacy Code. Meszaros is heavy reading but an excellent reference. Read Osherove first. Feathers' book is excellent if you have to work with code that has no tests.

Chapter 1 #available online at [...] is a brief but helpful introduction to unit testing and TDD #Test Driven Development#. I'd recommend it for anyone who is new to these subjects.

Chapters 2-5 teach how to use test and mock frameworks. They are .NET specific in the sense that the author uses NUnit and Rhino Mocks, but the definitions and descriptions in those chapters are applicable to other frameworks as well. I haven't tried it, but I suspect that the code could be put in C++ classes and run under Google Mocks & Test without many changes.

Chapters 6-7 are the heart of this book. They teeach how to write good tests and how to organize them. If you're already doing TDD, you could skip the rest of the book and just read these two chapters. They're worth the price of admission.

The last two chapters discuss how to introduce TDD to an organization and how to deal with legacy code. Osherove is a consultant, so he has had plenty of experience with introducing TDD. His suggestion to bring in a consultant is a bit self-serving, but has some merit. The legacy code chapter is mostly an overview of Feathers' book, but a good one.

In the book's preface, the author recounts an experience he had with a failed project where although unit tests were getting written, they apparently were so brittle (e.g., there were tests unnecessarily relying on or calling out to other tests) that when the development team had to respond to requirements changes, they found several tests breaking all at once with small changes to their code. Concluding that the tests were doing more harm than good to the project, the development team ended up throwing most of them away a few months into the project. From this experience, the author started compiling bad and good practices for writing, managing, and maintaining unit tests in the real world, and he shares some of his hard-earned knowledge with us in this book.

In the first half of the book (Chapters 1-5), the author introduces us to his idea of what unit testing ought to achieve, and teaches us how to write basic unit tests with and without the benefits of using frameworks popular in the .Net community (e.g., NUnit, RhinoMock, TypeMock, etc). He explains what setups and teardowns are, what stubs and mocks are, and when to use stubs or mocks (e.g., when the code under test has external dependencies; use stubs to test return values; use mocks to make assertions about method calls, etc).

In the next two chapters (Chapters 6-7), he tells us why unit tests ought to be trustworthy, maintainable, and readable, and how to write tests that strive for these qualities by recognizing bad (e.g., using setup to initialize variables that are only used in some test cases) and good (e.g., naming tests using a MethodUnderTest_Scenario_ExpectedBehavior convention [Divide_WithZeroDenominator_ThrowsException] ) practices. He also shows us how to treat unit test code with the same kind of care as production code; that is, unit test code should be subject to peer review, refactoring, etc.

In the final two chapters (Chapters 8-9), he shares some tips on how to introduce unit testing practices to organizations that still haven't adopted such practices, and how to tackle unit testing issues involving legacy code. Finally, Appendix A contains some of his views regarding Designing for Testability (some of which I don't agree with), and Appendix B contains descriptions for various testing tools.

Most books on testing tends to cover only the mechanics of how to use a particular framework for writing tests without giving additional guidance on how to make the tests effective and useful for a long time, as this book's author had done. Except for the first half of Chapter One where I thought the writing was a bit boring, and in a few other places where the author tended to be repetitive/redundant, I thought the author wrote really well and he was clearly very knowledgeable, experienced, and pragmatic. I thought the book is a little bit pricey, and would benefit mostly novice to intermediate developers only.

I've been teaching myself to design software and code for twenty years or more. Began pre-windows with a product called RBase, then later migrated to VB4 if that tells you anything. When it comes to testing, I suck. I think about the very first app I wrote in 1987 as my reference point to the UI. I debugged it to Hades and back and was quiet proud of the job. Then I watched a user switch off her 286 machine as she walked past me going to lunch without first exiting the program. I stood there in shock. That hadn't occurred to me. My database keys were a scrabbled mess that took a long, long week to put together again.

This book is teaching me to test the right way, early--if not before--I write hours and hours of code. I love it. Its readable, practical, and has plenty of code downloads to guide me when I'm confused about this whole idea of "simple".

Simple is really hard for some reason, and the book does a good job of pulling me down to simple, because simple means maintainable. Maintainable means happy, less coffee, and more time for the family. I like maintainable, and I love this primer on Unit testing too.

This book is a real must in your collection if you are interested in unit testing. No matter you are a beginner or an expert about this matter, this book will really teach you a lot of really useful and practical things.

And also this book is a useful read if you are planning to introduce unit testing in your company: it contains advices and patterns in order to organize and deploy a lot of good testing practiques.

Do not forget to have a look to the appendixes: there is a vast and complete summary of unit testing (and related) tools and frameworks that should be analized carefully.

Best regards from Spain!