Home - Java

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!

It is no longer needed to discuss the need for unit tests. Indeed, this technique becomes increasingly widespread in the computer world, whatever the language, and, when those tests are well crafted, they can significantly improve the quality of software, while facilitating the maintenance of the product. Unit tests can detect any new bug introduced in the product, and can therefore avoid regressions in the code.

The question that often remains unresolved is how to produce "good" unit tests. The literature contains a large number of books discussing methods (Agile, XP, Scrum), but there was no (in any case, for. NET) book explaining clearly how to produce some quality unit tests. That is the goal of The Art Of Unit Testing .

The book begins with an introduction to NUnit, and a set of definitions. It then moves quickly enough to a bit of practice with a first unit test.

The next section develops the concept of mock and stubs, and discusses in depth the Rhino Mocks framework. This part furthermore presents a set of good practices related to the use of this Framework, or any other isolation framework.

After discussing the building blocks of unit tests, the third part presents a set of good practice for the tests themselves, to avoid (among other issues) that the maintenance cost of the tests exceeds the advantage gained by their existence.

The last part of the book is looking at a level above, and presents the different points to keep in mind when introducing unit tests in an organization and especially in an existing project, which can represent a large proportion of cases when introducing unit testing in a team or project.

My biggest apprehension with this book was that, with Roy Osherove working for TypeMock, he would speak mostly of the commercial tools develpped by TypeMock (Isolator, Ivonna and co.). In fact, these tools are only marginally mentioned in this book, which focuses on 'standards' such as NUnit and Rhino Mocks.

All in all, this book is probably the best introduction to unit tests I've ever read, and should, in my opinion, be required reading for any team or person decided to start unit tests. In any case, personally, this is the book that I would have loved to have two years ago, when I started writing tests.

That said, this book requires some development experience with the .NET framework to appreciate it properly, therefore I recommend it to people having at least 2 or 3 projects behind them.

As a rule, I do not leave reviews - too lazy for that. But for this book I'll make an exception. Here is why I liked it:
- Biggest problem with unit testing is that if used incorrectly, it will ruin your project. This book shows you the way around problems you cannot see without experiencing them firsts - saves you A LOT of time.
- Right size, concentrated material, can be finished in 2-3 days.
- Every chapter matters.

The Art of Unit Testing is the best fit for developers who had some hands-on experience in unit testing but wasn't very successful with it.

I am a software developer on a team which presently numbers 15. We have a large corporate intranet portal with hundreds of separate and interrelated applications, and have never done unit testing. Recently we began preparing to incorporate unit tests into our process; another team member and I are in charge of making this happen. It's our job to train ourselves and the whole team until we all are comfortable with and skilled at creating unit tests.

I bought Art of Unit Testing and started my education. Initially I was put off by the fact that the author relies on NUnit for test creation; our developers all have Visual Studio Team Suite, which contains features specifically for test creation, and that's what we'll be using. However, a bit of research showed that the tests are essentially interchangable; there are certain "attributes" which are different (for example, NUnit's "TestFixture" becomes "TestClass" for VS Tests), and once I knew those, Mr. Osherove's example code worked fine in the VS Team environment without NUnit.

My teammate scheduled an instructional meeting to make the initial presentation to our team, so I loaned him my copy of Art of Unit Testing. The next day he raved to me about how great the book was: "It practically wrote my presentation for me. Everything I will say is coming straight out of that book." His presentation covered the basics from chapters one and two: rationale for unit testing, properties of a good unit test, comparing integration testing to unit testing, and a quick overview of test-driven development.

Next week it was my turn to teach. I borrowed heavily from chapters three and four, even down to using Mr. Osherove's LogAnalyzer Class as the target to be tested. We walked through creating a test from scratch, proper test method naming convention, attributes for class and test initialization and cleanup, testing a method which returns void, testing for thrown exceptions, and how to manually create and use stubs and mocks. Thanks to this book, my presentation was informative, concise and ordered logically (just like the book is). Our next class (still future as of this writing) will cover Rhino Mocks (very well demonstrated in chapter five) and Typemock Isolator. After that, we'll have a class on best practices in test writing (probably direct plagiarism of chapter seven) and later, a class based on chapter nine, Working with Legacy Code (we have a bunch of it here).

Art of Unit Testing has become our development team's class textbook (I know that at least four team members now have a copy and are studying it), and it is an excellent one, guiding us as teachers and leaders to be knowledgable and able to impart that knowledge in a clear, straightforward manner to our team. I have no doubt that with this book as our guide we'll be able to accomplish the goal of chapter eight: "Integrating Unit Testing Into the Organization".

One thing to note is that in his example code Mr. Osherove sometimes references classes whose source code does not appear in the book. No problem; just download it from his website. It's all there. I stepped through all but the most simplistic of the example code. It works as it should; no errata there (or anywhere else, that I could see).

I thought this book was okay for starting out unit testing. I don't think it gives a developer enough ground work to successfully use unit testing on their first project, but it does explain how to avoid many common pitfalls. Ultimately, I found the book to be hideously derivative, constantly referencing Meszaros' and Feather's books. This was really a beginner's version of Meszaros's version, great for just getting started. Unfortunately, I think it missed various opportunities to explain how to use mock objects to verify interactions with dependencies, which is often more common than checking return values. I was reading this book to review some key points and gain confidence to give a short symposium. Needless to say, I delayed the meeting.

Excellent book on unit level testing. The order give also access to pdf, kindle, epub versions as well.
The item was well packed and delivered in prompted manner, even oversea.
Thank you!

Only a few chapters in, but a very good book. Roy seems very good so far about taking a moment to be very clear about the *reasons* behind doing something. As a developer, I find this to be one of the things I spend some time thinking about.

This book provides great insight into unit testing and TDD in .NET. To be honest I bought this book when I started doing TDD and unit testing and it stayed as a reference book. I even ordered a copy for my company's library, and everybody starting out is pointed to this title first.
I think Roy went here far beyond the classic calculator example and covered every single aspect of unit testing. A lot of material is covered from unit testing frameworks to isolators to figuring out what is a stub and what a mock. If you want to start out practically to use unit testing this is a great book to start with.

Hello,

I'd like to thank the author of this book for writing it.

I've been writing unit tests for quite some time now and this book contributed my knowledge tremendously.

Before this book, I had a lot of questions to ask about unit testing and most of them where "how?" questions.

How to write a good unit test ?

How to write tests in isolation and decouple the dependencies in complex scenarios ?

How to write fake objects properly and understand the differences between the various fake objects in Unit Testing.

How to write scalable and maintainable unit tests ?

The only thing I dislike and I think the author should reconsider is the remark about virtual methods "Make methods virtual by default" while this may be convenient it comes with serious implications and I think there's a lot more to write about it rather than suggesting developers that they should do so, even though he wrote an alternative, the title says it all.

However, this book definitely stands for its title!

This is an excellent intro to unit testing. Easy to read, clear and with very good examples. I was glad to see the author used freeware libraries (nunit, rhino mocks) for the examples so anyone can learn with them (and then apply the principles to different libraries of they chose). This was exceptionally gratifying since he worked for a company that produced a competing commercial product at the time.

After I read this I told the rest of my team to buy a copy.

This is a wonderfully comprehensive introduction to unit testing. He covers IoC/DI in depth, as well as many popular mocking frameworks (including Rhino.) He goes on in the closing chapters to discuss good test design/structure.

The text is very well written, and makes for a smooth read. Highly highly recommend.

A great resource for people beginning Unit Testing or people refining their skills. The book covers good subject matter such as Unit Testing, Integration Testing, Mocking and stubbing. Good amount of samples and theory.

I bought this book because I had to start writing some serious unit tests and I didn't have a good idea of what to do.

Of course, if you are at the point you have to write unit tests, you have a job programming, so this book is certainly not for beginners (at least not in computing). The examples are in C# but the language is not very important for this book

He uses a different set of programs as the base of his examples, but this doesn't matter much, because the techniques he presents are very useful. The very first unit test I wrote after reading only a couple of chapters was way better, and easier to write and understand than the one I wrote just before it. And the one after I finished the book was even better.

As he mentions somewhere in the book, any type of testing is viewed as a waste of time, but the quality of the code improves a lot. He presents not only how and why to start writing unit tests but how to convince your company how to do it.

The book paid for itself a couple of times already, even though I only had it for about a month.

This is a great book for unit testing beginners and those who want to write better unit tests. There are a couple drawbacks mostly related to formatting/presentation but the content is top quality. Highly recommended.

As a developer who started working in Visual Basic 15 years ago and only began to explore unit testing and Test-Driven Development (TDD) in the last four to five years, I was blown away by The Art of Unit Testing. I wish this book had been written many years earlier. The code samples in the book are written in C# and the tools referenced target .NET, but the concepts apply to any language or platform.

This book should be read by anyone doing Unit Testing (especially the beginner). The content is written in a clear/concise manner and the examples are very good. The only thing that would make the book better is if the all the example code for NUnit/RhinoMocks were available for other frameworks like MBUnit/MOQ. It is not to hard to convert the examples to whatever testing frameworks you use, but it would be nice to have the examples already available for other frameworks. I know that is not the standard way of doing these type of books, but it would be nice.

I would recommend this book to others, and it is a book I will probably read multiple times.

What more can I say? Wish I'd read this 3 or 4 years ago. A must read for developers using .NET or other modern framework.

I love this book, for a intermediate unit tester, this book not only furthered my knowledge of unit testing, but it also showed me alot about rhino mocks which is taking unit testing to the next level. This books also give you alot of insight on how to sway a development team towards the idea of incorporating unit testing into a reluctant group. Open your minds and let the unit test philosophy in brothers.

-Mark

I loved this book right from the index page. Truly practical and result oriented. Thorough coverage of unit testing and integration testing. Another approach I liked is the author took a very pragmatic approach to unit testing. The section "Working with Legacy Code" is the icing on the cake. This is very useful if you are maintaining someone else's code.

In short the book walks the talk and is highly recommended to those who wish to take up unit testing in their day to day work. It sets the context straight.

First off, I've been doing unit testing for a while now. Very basic testing, at that. My existing tests, before I read this book, were rather hack-and-slash, with no serious organization, naming, or coding standards. They really only covered the low-hanging fruit of the code under test, and didn't cover any code that had dependencies. With the stage set, on to the book.

I won't discuss every chapter of the book, as that has been done already. I will comment on specific ones of value to me.

Chapters 3 and 4 were very educational for me, as they covered stubs and mocks, a subject I was unfamiliar with previously. Now that I know what they are and when, where, and how to use them, I will be able to simplify my unit tests.

Chapter 7, about the pillars of unit tests, is worth the cost of the book. It emphasizes the importance of the trustworthiness, readability, and maintainability of your test code.

There are two appendices, one on designing code for testability, and one listing various tools and frameworks to assist the unit testing process. These are good to have at hand.

Now going back to where I started this review: after having read this book, I can see ways that my test code can be improved. I've already started naming my test cases in a standard manner, and organizing test classes so they parallel the code under test. I have started using dependency injection to enable testability, and my code coverage has risen as a result. I will be reviewing my tests for the qualities, or lack thereof, mentioned in the chapter about pillars of unit tests.

As an aside, I would like to recommend an additional book: Working Effectively with Legacy Code, by Michael Feathers. Not to take away from this one, but the legacy code book is a fine choice to pair with this one. They are very complementary; Art of Unit Testing is about getting your code under test, while Working Effectively with Legacy Code is about refactoring your code to make it testable. Roy actually mentions the legacy code book in passing, and recommends it.

If you are not already a guru on unit testing, and are looking to improve your knowledge on the subject, this book is for you. I recommend it.

So, I ordered this book along with a few others when my team was about to start writing unit tests. Of all the books I ordered, this one was the most packed with realistic, hands-on guidance on how to organize your tests, and wide-ranging best practices and test patterns for how to write tests that are easy to maintain.

Roy Osherove has a lot of experience helping companies with "the art" of unit testing. He believes the key to successful unit testing rests on three pillars: maintainability, readability, and trustworthiness. He explains in the book what those things actually look like in real-world examples and why you might not be getting everything you could be out of your tests if you overlook one of those.

Roy also includes a fairly detailed comparison of the latest tools and frameworks you have to choose from. This section alone could save a ton of research time by getting a fairly unbiased, expert's view of the pros and cons for these types of tools and frameworks:
- Test Frameworks: NUnit, MSTest, MbUnit, Gallio, xUnit, Pex
- Isolation Frameworks: Moq, Rhino Mocks, Typemock Isolator, NMock, NUnit.Mocks
- IoC Containers: StructureMap, Unity, Castle Windsor, Autofac, Common Service Locator (CSL), Spring.NET, Managed Extensibility Framework (MEF), Ninject
- Web Testing: Ivonna, VS Team System Web Test, NUnitAsp, Watir, WatiN, Selenium
- UI Testing: NUnitForms, Project White, Team System UI Tests
- Thread-Related Testing: Typemock Racer, Microsoft CHESS
- Acceptance Testing: FitNesse, StoryTeller

This book was a short 320 pages, but there is a ton of practical and applicable tips jammed between the covers. But, I have to mention that this book isn't as polished as you would probably expect with most published works. It isn't anything major, but just a few things in the text or code samples that should have been caught by testers or an editor. These issues don't really take away from the content, but it just wasn't up to the standard I expect when buying a published work. (And that is possibly the worst cover I have ever seen ... yes, I get the reference to "The Art of War").

If you are remotely interested in this topic, you should listen to a recent podcast Roy did with Scott Hanselman on "The Art of Unit Testing." Although the podcast is kind of like a cliff-notes version of the book ... it isn't a replacement. If you find the podcast remotely helpful, order the book.

To read the full review or view more technical book reviews like this, visit [...].

I have been a .NET developer for over 6 years now and honestly have not had a real need for unit testing until recently. My current job and dept are slowing forcing all their developers to write up unit-testing proceedures for all of the application they have developed and I thought getting this book would be a very good idea.

This book covers unit testing in .NET from a pragmatic, yet thourough and passionate, perspective. It covers organizational topics such as how you introduce unit testing in an organization and how to do code reviews of tests.

The book begins with an introduction to NUnit, and a set of definitions. It then moves quickly enough to a bit of practice with a first unit test.

The next section develops the concept of mock and stubs, and discusses in depth the Rhino Mocks framework. This part furthermore presents a set of good practices related to the use of this Framework, or any other isolation framework.

After discussing the building blocks of unit tests, the third part presents a set of good practice for the tests themselves, to avoid (among other issues) that the maintenance cost of the tests exceeds the advantage gained by their existence.

The last part of the book is looking at a level above, and presents the different points to keep in mind when introducing unit tests in an organization and especially in an existing project, which can represent a large proportion of cases when introducing unit testing in a team or project.

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

A great buy and must read for any UNIT testers!

I would agree with most of the other reviews here. Roy's book is simply one of the best books ever written on unit testing. I would highly recommend this book to every developer.

Here are a few points that really sum up why this book stands out as the best...

*No Fluff - It's a slimmer book (320 pages), but packed with information. The size of the book makes it very approachable, and it's one of those books that you may want to read a few times to make sure everything really sinks in. It's a book you can recommend to just about everyone, regardless of their background.

*No Preaching - One key thing that sets this book in a class by itself is the fact that it doesn't focus on specific methodologies (like TDD), but is simply a guide to unit testing. The book doesn't assume anything or force any one way of practicing the art. Fully devoted to TDD, great. Could care less about TDD? This book is for you as well.

*Independent - Despite the fact that Roy works for Typemock, the majority of examples found in the book use open-source "mocking" or isolation frameworks. Throughout the book, no one tool is pushed over another. Roy does a good job of going over the pros and cons of many different tools, from many vendors.

*Inspiring - From the initial chapter on, this book not only educates, but it truly inspires. This is one of those books that gets you ramped up to do something. Whether it is starting unit testing within your organization, or enhancing existing tests, you'll want to start right away. It's that feeling we geeks get when a new version of software is released. I know I'm not the only one who goes to software conferences and such, and feels like jumping head first into the latest and greatest.

[...]

This book was a huge breakthrough for me as far as understanding the type of testing that goes on in our organization, integration testing, not unit testing! Before I read Roy's book I thought that I was looking for evidence on Test Driven Development but I found out that the real prize I was interested in was automated unit testing. Our large organization needs to evolve to better testing methods and I have integrated many of the concepts from this book into my recommendations to management. I recently developed a presentation for a developer's user group meeting that focused on unit testing with material from this book featured prominently. The book was very easy to understand and well written.

And Typemock Isolator is the greatest thing ever. Isolate.WhenCalled(() => ProblematicMethodThatInteractsWithTheFileSystemOrInternetOrDatabase()).IgnoreCall()! Thank you Roy! You are my god!

First time when I familiarized with unit testing was 5 or 6 years ago. It was start of my developing career. I remember that somebody told me about code coverage. At that time I didn't write any Unit tests. Guy, who was my team lead, told me "Do you see operator if with three conditions? You should check all of these conditions". So, after that I had written some code, I should go to interface and try to invoke all code which I wrote from user interface. Nice? At current time I know little more about tests and unit testing. I have not participated in projects, designed by Test Driven Development (TDD). Basics of my knowledge are a spying code of my colleagues, some articles and screencasts. I had decide that I should know much more, and became a real professional of unit testing, this is why I had start to read book The art of Unit Testing with Examples in .NET. More than, in my current job place looks like I'm just one who writing unit tests for my code. I should show good examples of my tests.

The book was written about half year ago. Most of samples was written with C#. I saw a lot of recommendation for reading this book.

Author of this book is Roy Osherove. He is famous blogger, also he is lecturing TDD master classes, sometimes he is working consultant for IT companies, if they want to implement TDD in their projects (he wrote not one time about this, bring successful and unsuccessful cases). He is working as a main architect in company Typemock. Typemock developing paid instruments for tests/unit testing and code analysis.

The book will be useful for developers of any platforms. Like I said before most of examples was written with C# (some of examples with Java). In book author use NUnit framework for unit tests, Rhino Mocks for Mock and Stub objects in Unit tests (before that I didn't know that Stub and Mock are different, I knew only about Mocks).
So, what you will find in the book? You can download a few chapters from official book's site, so before buy the book you can read first is it good for you or not. First chapter of book is "Hello world!". It is about what you need to write tests, what kind of frameworks, tools, and of course first test is there. Next chapter about frameworks which author use in his book: NUnit and Rhino Mocks. He used Rhino Mocks at book as I understand because he got statistic that Rhino Mocks is frequently used framework for creating Mocks and Stubs. I think that today situation little different, I like Moq. And NUnit today is still most used unit testing framework. One time I used MbUnit, because it has more features, but NUnit today has the same features.

It the book you will find information about how to write tests, how you should design them. And also you will find antipatterns: I found out all of them, I had used them in my code. :(

Also I found answer for my old question. I wrote some article about testing applications with NHibernate, and I got comment about why you are testing ORM? I thought that this man know more than me in unit testing, so really maybe I shouldn't test ORM Repositories. At that time I had really specific case, so I said that I need it, and said why I need these tests. I didn't know why this guy asked me this question. Really this is my integration test. With this test I check that database schema is equal to xml-mapping, mapping is equal to classes, and if I use special queries I check them too with my tests. It is really helpful. In the book I found answer for my question - tests for ORM is really helpful, author if this book always write tests for his Data Access Layer, and he said why.

Also in the book you will find how to introduce TDD in your company, how to work with Legacy code (this is really important when you introduce TDD in exist project, not new). Also a lot of questions and answers for guy, who want to introduce TDD in his group/company, he will get a lot of questions for his colleagues (money, time, knowledge, etc).

At the end of book author made an inventory of frameworks, which you can use for testing. Of course in his list you will find paid frameworks, which was written by Typemock, where author are working.

Really I recommend this book for all companies, which use TDD in their practice and which write unit tests, so for all companies. My recommendation for team leads and managers, don't say "You must write tests", read book first, or ask your colleagues to read the book, make a lectures, trainings, and you will see the result.

This is a good book for the intermediate developer.
For beginner to NUnit, I would recommend the Pragmatic Series.