Jay Fields - Working Effectively with Unit Tests

Over a dozen years ago I read Refactoringfor the first time; it immediately became my bible.While Refactoring isnt about testing, it explicitly states: if you want to refactor,the essential precondition is having solid tests. At that time, if Refactoring deemed itnecessary, I unquestionably complied. That was the beginning of my quest to create productiveunit tests.

Throughout the 12+ years that followed my first reading of Refactoring I made many mistakes, learnedcountless lessons, and developed a set of guidelines that I believe make unit testing aproductive use of programmer time. This book provides a single place to examine thosemistakes, share the lessons learned, and provide direction in a way that Ive foundto be the most effective.

The answer was easy for me: Refactoring told me to. Unfortunately, doing something strictlybecause someone or something told you to is possibly the worst approach you could take.The more time Ive invested in testing, the more Ive found myself returning to the question:Why am I writing this test?

There are many motivators for creating a test or several tests:

• validate the system
  • immediate feedback that things work as expected
  • prevent future regressions
• increase code-coverage
• enable refactoring
• document the behavior of the system
• your manager told you to
• Test Driven Development
  • improved design
  • breaking a problem up into smaller pieces
  • defining the simplest thing that could possibly work
• customer acceptance
• ping pong pair-programming

Some of the above motivators are healthy in the right context, others are indicators of largerproblems. Before writing any test, I would recommend deciding which of the above are motivatingyour testing. If you first understand why youre writing a test, youll have a muchbetter chance of writing a test that is maintainable and will make you more productive in thelong run.

Once you start looking at tests while considering the motivator, you may find you have teststhat arent actually making you more productive. For example, you may have a test that increasescode-coverage, but satisfies no other motivator. If your team requires 100% code-coverage, then thetest provides value. However, if your team has abandoned the (in my opinion harmful) goal of 100%code-coverage, then youre in a position to perform my favorite refactoring: delete.

This book is aimed at a professional programmer, someone who writes software for a living. Theexamples and discussion include a lot of code to read and to understand.

Although this book is focused on testing, testable codecan have a large impact on the design of a system.It is vital for senior designers and architects to understandthe principles recommended and to use them in their projects.The principles within this book are best introduced to a teamby a respected and experienced developer. Such a developer canbest understand the principles and adapt themto their specific context. In addition, familiarity with this bookscontent will allow experienced developers to provide it as a referencefor the less experienced members of their team.

Despite my opinion on who should introduce these concepts, Ive attempted to write this bookfor both people experienced with and those brand-new to unit testing. Ideally, a respectedprogrammer will look to implement the ideas within this book, and begin by passing this bookon to those on the team that would likely share interest in this approach.If youre already writing testsI believe this book will provide concepts and suggestions that will prove usefulfor years to come. If you arent already writing tests youlllikely want to pick up an intro to unit testing book as well. The concepts in this bookshould be understandable to developers of all levels; however, we will not coverconcepts such as framework selection, framework configuration, or writing your first test.

While this book does contain an Acknowledgments section, it wouldnt be practical to thankeveryone that has contributed to creating the practices that this book details. I can say withfull confidence that I wouldnt be in the position to write this book without at least thefollowing groups:

• creators and maintainers of both NUnit and JUnit
• creators and maintainers of NMock, (James Meads) Mocha, Mockito, JMock, and RSpec
• each team member from each of my projects at ThoughtWorks & DRW Trading
• every conference speaker or attendee whos provided feedback on my (sometimes radical) ideas
• every person who left a comment on blog.jayfields.com

Thank you all, I deeply appreciate the feedback youve given throughout the years.