Art of Unit Testing

Roy Osherove consults and trains teams worldwide on the gentle art of unit testing and test-driven development, and trains team leaders how to lead better at 5whys.com. He tweets at @RoyOsherove and has many videos about unit testing at ArtOfUnitTesting.com. His testing blog is at http://osherove.com/blog.

foreword to the second edition
foreword to the first edition
preface
acknowledgments
about this book
about the cover illustration

Part 1 Getting started

Chapter 1 The basics of unit testing
Defining unit testing, step by step
Properties of a good unit test
Integration tests
What makes unit tests good
A simple unit test example
Test-driven development
The three core skills of successful TDD
Summary
Chapter 2 A first unit test
Frameworks for unit testing
Introducing the LogAn project
First steps with NUnit
Writing your first test
Refactoring to parameterized tests
More NUnit attributes
Testing results that are system state changes instead of return values
Summary

Part 2 Core techniques

Chapter 3 Using stubs to break dependencies
Introducing stubs
Identifying a filesystem dependency in LogAn
Determining how to easily test LogAnalyzer
Refactoring your design to be more testable
Variations on refactoring techniques
Overcoming the encapsulation problem
Summary
Chapter 4 Interaction testing using mock objects
Value-based vs. state-based vs. interaction testing
The difference between mocks and stubs
A simple handwritten mock example
Using a mock and a stub together
One mock per test
Fake chains: stubs that produce mocks or other stubs
The problems with handwritten mocks and stubs
Summary
Chapter 5 Isolation (mocking) frameworks
Why use isolation frameworks?
Dynamically creating a fake object
Simulating fake values
Testing for event-related activities
Current isolation frameworks for .NET
Advantages and traps of isolation frameworks
Summary
Chapter 6 Digging deeper into isolation frameworks
Constrained and unconstrained frameworks
Values of good isolation frameworks
Features supporting future-proofing and usability
Isolation framework design antipatterns
Summary

Part 3 The test code

Chapter 7 Test hierarchies and organization
Automated builds running automated tests
Mapping out tests based on speed and type
Ensuring tests are part of source control
Mapping test classes to code under test
Cross-cutting concerns injection
Building a test API for your application
Summary
Chapter 8 The pillars of good unit tests
Writing trustworthy tests
Writing maintainable tests
Writing readable tests
Summary

Part 4 Design and process

Chapter 9 Integrating unit testing into the organization
Steps to becoming an agent of change
Ways to succeed
Ways to fail
Influence factors
Tough questions and answers
Summary
Chapter 10 Working with legacy code
Where do you start adding tests?
Choosing a selection strategy
Writing integration tests before refactoring
Important tools for legacy code unit testing
Summary
Chapter 11 Design and testability
Why should I care about testability in my design?
Design goals for testability
Pros and cons of designing for testability
Alternatives to designing for testability
Example of a hard-to-test design
Summary
Additional resources

appendix Tools and frameworks

index

»This book is something special. The chapters build on each other to a startling accumulation of depth. Get ready for a treat.« From the Foreword by Robert C. Martin, cleancoder.com

»The best way to learn unit testing from what is now a classic in the field.« Raphael Faria. LG Electronics

»Teaches you the philosophy as well as the nuts and bolts for effective unit testing.« Pradeep Chellappan, Microsoft

»When my team members ask me how to write unit tests the right way, I simply answer: Get this book!« Alessandro Campeis. Vimar SpA

One of the smartest things I ever heard anyone say about learning (and I forget who it was), is that to truly learn something, teach it. Writing the first edition of this book. and publishing it in 2009, was nothing short of a true learning experience for me. I initially wrote the book because I got tired of answering the same questions over and over again. But there were other reasons too. I wanted to try something new; I wanted to try an experiment; I wondered what I could learn from writing a book—any book. Unit testing was what I was good at. I thought. The curse is that the more experience you have, the more stupid you feel. There are parts of the first edition that today I do not agree with—for example, that a unit refers to a method. That’s not true at all. A unit is a unit of work, as I discuss in chapter 1 of this second edition. It can be as small as a method, or as big as several classes (possibly assemblies) … and there are other things as well that have changed, as you will learn below. What’s new in the second edition In this second edition, I added material about constrained versus unconstrained isolation frameworks, and a new chapter 6 on what makes for a good isolation framework and how frameworks like Typemock work under the covers. I no longer use RhinoMocks. Stay away from it. It is dead. At least for now. I use NSubstitute for examples of Isolation Framework Basics, and I also recommend FakeItEasy. I am still not crazy about MOQ, for reasons detailed in chapter 6. I added more techniques to the chapter about implementing unit testing at the organizational level. There are plenty of design changes in the code I show in the book. Mostly I stopped using property setters and am mostly using constructor injection. Some discussion of SOLID principles is added, but just enough to make it whet your appetite on the subject. The build related sections of chapter 7 also contain new information. I learned a lot since the first book about build automation and patterns. I recommend against setup methods, and give alternative ideas on getting the same functionality out of your tests. I also use newer versions of Nunit so some of the newer Nunit APIs changed in the book. In chapter 10, the tools relating to legacy code were updated. Having worked with Ruby for the past three years along side .NET, gave me more perspective about design and testability arguments, reflected in chapter 11. The tools and frameworks appendix was updated with new tools, and old tools were removed. Who should read this book The book is for anyone who writes code and is interested in learning best practices for unit testing. All the examples are written in C# using Visual Studio, so .NET developers will find the examples particularly useful. But the lessons I teach apply equally to most, if not all, object-oriented and statically typed languages (VB.NET, Java, and C++, to name a few). If you’re an architect, developer, team lead, QA engineer (who writes code), or novice programmer, this book should suit you well. Roadmap If you’ve never written a unit test, it’s best to read this book from start to finish so you get the full picture. If you have experience, you should feel comfortable jumping into the chapters as you see fit. The book is divided into four parts. Part 1 takes you from zero to 60 in writing unit tests. Chapters 1 and 2 cover the basics, such as how to use a testing framework (NUnit), and introduce the basic automated test attributes, such as [Test] and [TestCase]. They also introduce the ideas of asserts, ignoring tests, unit-of-work testing, the three end result types of a unit test, and the three types of tests you need for them: value tests, state-based tests, and interaction tests. Part 2 discusses advanced techniques for breaking dependencies: mock objects, stubs, isolation frameworks, and patterns for refactoring your code to use them. Chapter 3 introduces the idea of stubs and shows how to manually create and use them. Chapter 4 introduces interaction testing with handwritten mock objects. Chapter 5 merges these two concepts and shows how isolation frameworks combine these two ideas and allow them to be automated. Chapter 6 dives deeper into understanding constrained and unconstrained isolation frameworks and how they work under the covers. Part 3 talks about ways to organize test code, patterns for running and refactoring its structure, and best practices when writing tests. Chapter 7 discusses test hierarchies, how to use test infrastructure APIs, and how to combine tests in the automated build process. Chapter 8 discusses best practices in unit testing for creating maintainable, readable, and trustworthy tests. Part 4 talks about how to implement change in an organization and how to work on existing code. Chapter 9 discusses problems and solutions you’d encounter when trying to introduce unit testing into an organization. It also identifies and answers some questions you might be asked. Chapter 10 talks about introducing unit testing into existing legacy code. It identifies a couple of ways to determine where to begin testing and discusses some tools for testing untestable code. Chapter 11 discusses the loaded topic of designing for testability and the alternatives that exist today. The appendix has a list of tools you might find useful in your testing efforts. Code conventions and downloads You can download the source code for this book from GitHub at https://github.com/royosherove/aout2 or the book’s site at www.ArtOfUnitTesting.com, as well as from the publisher’s website at www.manning.com/TheArtofUnitTestingSecondEdition. A Readme.txt file is provided in the root folder and also in each chapter folder; the files provide details on how to install and run the code. All source code in listings or in the text is in a fixed-width font like this to separate it from ordinary text. In listings, bold code indicates code that has changed from the previous example or that will change in the next example. In many listings, the code is annotated to point out the key concepts and numbered bullets refer to explanations that follow in the text. Software requirements To use the code in this book, you need at least Visual Studio C# Express (which is free) or a more advanced version of it (that costs money). You’ll also need NUnit (an open source and free framework) and other tools that will be referenced where they’re relevant. All the tools mentioned are either free, open source, or have trial versions you can use freely as you read this book.

foreword to the first edition When Roy Osherove told me that he was working on a book about unit testing, I was very happy to hear it. The testing meme has been rising in the industry for years, but there has been a relative dearth of material available about unit testing. When I look at my bookshelf, I see books that are about test-driven development specifically and books about testing in general, but until now there has been no comprehensive reference for unit testing—no book that introduces the topic and guides the reader from first steps to widely accepted best practices. The fact that this is true is stunning. Unit testing isn’t a new practice. How did we get to this point? It’s almost a cliché to say that we work in a very young industry, but it’s true. Mathematicians laid the foundations of our work less than 100 years ago, but we’ve only had hardware fast enough to exploit their insights for the last 60 years. There was an initial gap between theory and practice in our industry, and we’re only now discovering how it has impacted our field. In the early days, machine cycles were expensive. We ran programs in batches. Programmers had a scheduled time slot, and they had to punch their programs into decks of cards and walk them to the machine room. If your program wasn’t right, you lost your time, so you desk-checked your program with pencil and paper, mentally working out all of the scenarios, all of the edge cases. I doubt the notion of automated unit testing was even imaginable. Why use the machine for testing when you could use it to solve the problems it was meant to solve? Scarcity kept us in the dark. Later, machines became faster and we became intoxicated with interactive computing. We could just type in code and change it on a whim. The idea of desk-checking code faded away, and we lost some of the discipline of the early years. We knew programming was hard, but that just meant that we had to spend more time at the computer, changing lines and symbols until we found the magical incantation that worked. We went from scarcity to surplus and missed the middle ground, but now we’re regaining it. Automated unit testing marries the discipline of desk-checking with a newfound appreciation for the computer as a development resource. We can write automated tests, in the language we develop in, to check our work—not just once, but as often as we’re able to run them. I don’t think there is any other practice that’s quite as powerful in software development. As I write this, in 2009, I’m happy to see Roy’s book come into print. It’s a practical guide that will help you get started and also serve as a great reference as you go about your testing tasks. The Art of Unit Testing isn’t a book about idealized scenarios. It teaches you how to test code as it exists in the field, how to take advantage of widely used frameworks, and, most importantly, how to write code that’s far easier to test. The Art of Unit Testing is an important title that should have been written years ago, but we weren’t ready then. We are ready now. Enjoy. MICHAEL FEATHERS foreword to the second edition The year must have been 2009. I was speaking at the Norwegian Developers Conference in Oslo. (Ah, Oslo in June!) The event was held in a huge sports arena. The conference organizers divided the bleachers into sections, built stages in front of them, and draped them with thick black cloth in order to create eight different session “rooms.” I remember I was just about finished with my talk, which was about TDD, or SOLID, or astronomy, or something, when suddenly, from the stage next to me, came this loud and raucous singing and guitar playing. The drapes were such that I was able to peer around them and see the fellow on the stage next to mine, who was making all the noise. Of course, it was Roy Osherove. Now, those of you who know me know that breaking into song in the middle of a technical talk about software is something that I might just do, if the mood struck me. So as I turned back to my audience, I thought to myself that this Osherove fellow was a kindred spirit, and I’d have to get to know him better. And getting to know him better is just what I did. In fact, he made a significant contribution to my most recent book The Clean Coder and spent three days with me coteaching a TDD class. My experiences with Roy have all been very positive, and I hope there are many more. I predict that your experience with Roy, in the reading of this book, will be very positive as well because this book is something special. Have you ever read a Michener novel? I haven’t; but I’ve been told that they all start at “the atom.” The book you’re holding isn’t a James Michener novel, but it does start at the atom—the atom of unit testing. Don’t be misled as you thumb through the early pages. This is not a mere introduction to unit testing. It starts that way, and if you’re experienced you can skim those first chapters. As the book progresses, the chapters start to build on each other into a rather startling accumulation of depth. Indeed, as I read the last chapter (not knowing it was the last chapter) I thought to myself that the next chapter would be dealing with world peace—because, I mean, where else can you go after solving the problem of introducing unit testing into obstinate organizations with old legacy systems? This book is technical—deeply technical. There’s a lot of code. That’s a good thing. But Roy doesn’t restrict himself to the technical. From time to time he pulls out his guitar and breaks into song as he tells anecdotes from his professional past or waxes philosophical about the meaning of design or the definition of integration. He seems to relish in regaling us with stories about some of the things he did really badly in the deep, dark past of 2006. Oh, and don’t be too concerned that the code is all in C#. I mean, who can tell the difference between C# and Java anyway? Right? And besides, it just doesn’t matter. He may use C# as a vehicle to communicate his intent, but the lessons in this book also apply to Java, C, Ruby, Python, PHP, or any other programming language (except, perhaps COBOL). If you’re a newcomer to unit testing and test-driven development, or if you’re an old hand at it, you’ll find this book has something for you. So get ready for a treat as Roy sings you the song “The Art of Unit Testing.” And Roy, please tune that guitar! ROBERT C. MARTIN (UNCLE BOB)