You can download the most up-to-date version of your electronic books from your Manning Account at .
Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.
Welcome
Thank you for purchasing the MEAP of Unit Testing: Principles, Practices, and Patterns.
Most online and print resources have one drawback: they focus on the basics of unit testing, but dont go much beyond that. Theres a lot of value in such resources, but the learning doesn't end there. There's a next level: not just writing tests, but doing it in a way that gives you the best return on your efforts. When you reach this point in the learning curve, youre pretty much left to your own devices figuring out how to get to that next level.
This book takes you to that next level. It teaches a scientific, precise definition of the ideal unit test. This definition provides a universal frame of reference. After learning it, you will be able to look at many of your tests in a new light and see which of them contribute to the project and which must be refactored or gotten rid of altogether.
If youre an experienced programmer, you most likely already get at the intuitive level some of the ideas taught in this book. This book will help you articulate why the techniques and best practices you've been using all along are so helpful. And don't underestimate this skill: the ability to clearly communicate your ideas to colleagues is priceless.
You dont need to be an expert in unit testing, though youll get more out of this book if you have some unit testing skills. If you don't have much experience with unit testing techniques and best practices, youll learn a lot. In addition to the frame of reference, which you can use to analyze any test in a test suite, the book teaches
- How to refactor the test suite along with the production code it covers.
- How to apply different styles of unit testing.
- Using integration tests to verify the behavior of the system as a whole.
- Identifying and avoiding anti-patterns in unit tests.
In addition to unit tests, this book covers the entire topic of automated testing, so youll also learn about integration and end-to-end tests.
Your feedback is essential to creating the best book possible. Please be sure to post any questions, comments, or suggestions you have about the book in the liveBook Discussion Forum.
Vladimir Khorikov
Brief Table of Contents
Part 1:
Part 2:
Part 3:
Part 4:
Part 1
The bigger picture
This part of the book will get you up to speed with the current state of unit testing.
In chapter 1, Ill define the goal of unit testing and give an overview of how to differentiate a good test from a bad one. Well talk about coverage metrics and discuss properties of a good unit test in general.
In chapter 2, well look at the definition of "unit test". A seemingly minor disagreement in this definition has led to formation of two schools of unit testing, which well dive into in that chapter too.
Chapter 3 provides a refresher on some basic topics, such as structuring of unit tests, reusing test fixtures, and test parametrization.
The goal of unit testing
This chapter covers:
The state of unit testing
The goal of unit testing
Consequences of having a bad test suite
Using coverage metrics to measure test suite quality
Attributes of a successful test suite
Learning unit testing doesnt stop at mastering the technical bits of it, such as your favorite test framework, mocking library, and so on. Theres much more to unit testing than the act of writing tests. You always have to strive to achieve the best return on the time you invest in unit testing, minimizing the effort you put into tests and maximizing the benefits they provide. Achieving both things isnt an easy task.
Its fascinating to watch projects that have achieved this balance: they grow effortlessly, dont require much maintenance, and can quickly adapt to their customers' ever-changing needs. Its equally frustrating to see projects that failed to do so. Despite all the effort and an impressive number of unit tests, such projects drag on slowly, with lots of bugs and upkeep costs.
Thats the difference between various unit testing techniques. Some yield great outcomes and help maintain software quality. Others dont: they result in tests that dont contribute much, break often, and require a lot of maintenance in general.
What you learn in this book will help you differentiate between good and bad unit testing techniques. Youll learn how to do a cost-benefit analysis of your tests and apply proper testing techniques in your particular situation. Youll also learn how to avoid common anti-patternspatterns that may make sense at first but lead to trouble down the road.
But lets start with the basics. This chapter gives a quick overview of the state of unit testing in the software industry, describes the goal behind writing and maintaining tests, and provides you with the idea of what makes a test suite successful.
1.1 The current state of unit testing
In this section, I give a high-level overview of why unit testing is a good thing, and how unit testing is evolving. For the past two decades, theres been a push toward adopting unit testing. The push has been so successful that unit testing is now considered mandatory in most companies. Most programmers practice unit testing and understand its importance. Theres no longer any dispute as to whether you should do it. Unless youre working on a throw-away project, the answer is: you do.
When it comes to enterprise application development, almost every project includes at least some unit tests. A significant percentage of such projects go far beyond that: they achieve good code coverage with lots and lots of unit and integration tests. The ratio between the production code and the test code could be anywhere between 1:1 and 1:3 (for each line of production code, there are one to three lines of test code). Sometimes, this ratio even goes much higher than that, to a whopping 1:10.
But, as with all new technologies, unit testing continues to evolve. The discussion has shifted from "Should we write unit tests?" to "What does it mean to write good unit tests?" This is where the main confusion still lies.
You can see the results of this confusion in software projects. Many projects have automated tests; they may even have a lot of them. But the existence of those tests often doesnt provide the results the developers hope for. It can still take programmers a lot of effort to make progress in such projects. New features take forever to implement, new bugs constantly appear in the already implemented and accepted functionality, and the unit tests that are supposed to help dont seem to mitigate this situation at all. They can even make it worse.