More…

buy now: https://leanpub.com/wewut

join the discussion group (free): http://group.wewut.com

",{"_149":150,"_43":44,"_47":48,"_45":46,"_65":66,"_151":152,"_168":147},"previewContent","

\n Foreword\n
\n Preface\n
\n Acknowledgments\n
\n Unit Testing, a First Example\n
- \n Thoughts on our Tests\n
- \n The Domain Code\n
- \n Moving Towards Readability\n
- \n Replace Loop with Individual Tests\n
- \n Expect Literals\n
- \n Inline Setup\n
- \n Replace ObjectMother with DataBuilder\n
- \n Comparing the Results\n
- \n Final Thoughts on our Tests\n
\n
\n Motivators\n
\n More…\n

Foreword

\n\n

It’s taken quite a while but we finally have consensus around the idea\nthat unit testing is a necessity for most of today’s projects.\nOccasionally, I see a voice in the wilderness challenge the idea - but\njust as quickly people who’ve been doing unit testing reflect back on\ntheir experience and notice the benefits that they’ve received. The\nidea of going without unit tests on a large project is just\nunthinkable for many people.

\n\n

To me, this is success of the best kind - people are able to get more\nwork done with less stress and fewer headaches. But that doesn’t mean\nthat it’s all easy. Even though unit testing has been a strongly\nrecommended practice since at least the early 2000s, people still\nstruggle. They struggle because it is easy to get lost in the design\ndecisions that you have to make when you are writing tests.

\n\n

Tests are just as important as production code, but they are\ndifferent. Through trial and error we are learning better practices\nbut much of that knowledge is not yet widespread.

\n\n

This is why I am very excited by Jay Fields’ book. I’ve known Jay for\nclose to a decade and over that time I’ve seen him approach problems\nin software with conscientiousness and deep curiosity - trying things\nout, discussing them and not being satisfied with answers that don’t\nquite ring true. The book you’re about to read is a culmination of\nthat inquiry. Reading it, you’ll learn a lot about unit testing.\nBut, more than that, if you read between the lines you’ll learn a lot\nabout how to see and think about software.

\n\n

– Michael Feathers, Director, R7K Research & Conveyance

\n\n

Preface

\n\n

Over a dozen years ago I read Refactoring\nfor the first time; it immediately became my bible.\nWhile Refactoring isn’t about testing, it explicitly states: if you want to refactor,\nthe essential precondition is having solid tests. At that time, if Refactoring deemed it\nnecessary, I unquestionably complied. That was the beginning of my quest to create productive\nunit tests.

\n\n

Throughout the 12+ years that followed my first reading of Refactoring I made many mistakes, learned\ncountless lessons, and developed a set of guidelines that I believe make unit testing a\nproductive use of programmer time. This book provides a single place to examine those\nmistakes, share the lessons learned, and provide direction in a way that I’ve found\nto be the most effective.

\n\n

Why Test?

\n\n

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

\n\n

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

\n\n

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

Some of the above motivators are healthy in the right context, others are indicators of larger\nproblems. Before writing any test, I would recommend deciding which of the above are motivating\nyour testing. If you first understand why you’re writing a test, you’ll have a much\nbetter chance of writing a test that is maintainable and will make you more productive in the\nlong run.

\n\n

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

\n\n

Who Should Read This Book

\n\n

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

\n\n

Although this book is focused on testing, testable code\ncan have a large impact on the design of a system.\nIt is vital for senior designers and architects to understand\nthe principles recommended and to use them in their projects.\nThe principles within this book are best introduced to a team\nby a respected and experienced developer. Such a developer can\nbest understand the principles and adapt them\nto their specific context. In addition, familiarity with this book’s\ncontent will allow experienced developers to provide it as a reference\nfor the less experienced members of their team.

\n\n

Despite my opinion on who should introduce these concepts, I’ve attempted to write this book\nfor both people experienced with and those brand-new to unit testing. Ideally, a respected\nprogrammer will look to implement the ideas within this book, and begin by passing this book\non to those on the team that would likely share interest in this approach.\nIf you’re already writing tests\nI believe this book will provide concepts and suggestions that will prove useful\nfor years to come. If you aren’t already writing tests you’ll\nlikely want to pick up an intro to unit testing book as well. The concepts in this book\nshould be understandable to developers of all levels; however, we will not cover\nconcepts such as framework selection, framework configuration, or writing your first test.

\n\n

Building on the Foundations Laid by Others

\n\n

While this book does contain an Acknowledgments section, it wouldn’t be practical to thank\neveryone that has contributed to creating the practices that this book details. I can say with\nfull confidence that I wouldn’t be in the position to write this book without at least the\nfollowing groups:

\n\n

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

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

\n\n

Acknowledgments

\n\n

After writing Refactoring: Ruby Edition, I swore I’d never write another book. Book writing\nis unquestionably a labor of love, and I wouldn’t be able to do it without the support of\nmy many friends in the industry.

\n\n

Martin Fowler: Thank you for allowing me to reference and reuse content from\nRefactoring. It’s still my favorite technical book of all time.
Obie Fernandez: Thank you for the nudge to use leanpub; it was crucial for making this\nproject happen.
Michael Feathers: Honestly, I just liked the way Working Effectively with Unit Tests\nsounded. I never considered that anyone would associate this book with a book as\nuniversally loved as Working Effectively with Legacy Code. Nonetheless, I’ll do my\nbest to deliver a book that is worthy of being on the same shelf as\nWorking Effectively with Legacy Code. Thank you very much for your blessing.
Original Reviewers: There’s no question this book is significantly better\ndue to the feedback I got from those who originally volunteered to provide feedback.\nThank you Graham Nash, John Hume, Pat Farley, & Steve McLarnon.

Additionally, I’ve been happily surprised by the support I’ve gotten from\npeople who purchased the early edition on leanpub and promptly provided feedback.\nMany thanks - Allan Clarke, Corey Haines,\nDerek Reeve, J. B. Rainsberger,\nJake McCrary, Josh Graham, Kent Spillner, & Steve Vinoski.

\n\n

I’m sure there are others who I’ve forgotten; I apologize and offer my thanks.

\n\n\n

Unit Testing, a First Example

\n\n

I’d like to begin this book with an example, and I believe Martin’s description of why is\nas clear as it can be written:

\n\n

\n
Traditionally technical books start with a general introduction that outlines things like\nhistory and broad principles. When someone does that at a conference, I get slightly sleepy.\nMy mind starts wandering with a low-priority background process that polls the speaker\nuntil he or she gives an example. The examples wake me up because it is with examples that\nI can see what is going on. With principles it is too easy to make generalizations, too hard\nto figure out how to apply things. An example helps make things clear.\n–Martin Fowler, Refactoring: Ruby Edition
\n

\n\n

Note: If the following domain looks familiar to you, that’s because I’ve borrowed it from\nRefactoring.

\n\n

Without further ado, I present a test failure.

\n\n

JUnit version 4.11\n.E.E..\nThere were 2 failures:\n1) statement(CustomerTest)\norg.junit.ComparisonFailure: expected:<...or John\n\tGodfather 4[\t]9.0\nAmount owed is 9...> but was:<...or John\n\tGodfather 4[ ]9.0\nAmount owed is 9...>\n2) htmlStatement(CustomerTest)\norg.junit.ComparisonFailure: expected:<...</h1>\n<p>Godfather 4[\t]9.0</p>\n<p>Amount ow...> but was:<...</h1>\n<p>Godfather 4[ ]9.0</p>\n<p>Amount ow...>\n\nFAILURES!!!\nTests run: 4,  Failures: 2\n

\n\n

The above output is what JUnit will report (sans stacktrace noise) for the\n(soon to follow) CustomerTest class.

\n\n

Unless you work alone and on greenfield projects exclusively, you’ll often find\nyour first introduction to a test will be when it fails. If that’s\na common case you’ll encounter at work then it feels like a great way to start the book as well.

\n\n

Below you’ll find the cause of the failure, the CustomerTest class.

\n\n

public class CustomerTest {\n  Customer john, steve, pat, david;\n  String johnName = \"John\",\n    steveName = \"Steve\",\n    patName = \"Pat\",\n    davidName = \"David\";\n  Customer[] customers;\n\n  @Before\n  public void setup() {\n    david = ObjectMother\n      .customerWithNoRentals(\n        davidName);\n    john = ObjectMother\n      .customerWithOneNewRelease(\n        johnName);\n    pat = ObjectMother\n      .customerWithOneOfEachRentalType(\n        patName);\n    steve = ObjectMother\n      .customerWithOneNewReleaseAndOneRegular(\n        steveName);\n    customers =\n      new Customer[]\n      { david, john, steve, pat};\n  }\n

\n\n

  @Test\n  public void getName() {\n    assertEquals(\n      davidName, david.getName());\n    assertEquals(\n      johnName, john.getName());\n    assertEquals(\n      steveName, steve.getName());\n    assertEquals(\n      patName, pat.getName());\n  }\n\n  @Test\n  public void statement() {\n    for (int i=0; i<customers.length; i++) {\n      assertEquals(\n        expStatement(\n          \"Rental record for %s\\n\" +\n          \"%sAmount owed is %s\\n\"  +\n          \"You earned %s frequent \" +\n          \"renter points\",\n          customers[i],\n          rentalInfo(\n            \"\\t\", \"\",\n            customers[i].getRentals())),\n        customers[i].statement());\n    }\n  }\n

\n\n

  @Test\n  public void htmlStatement() {\n    for (int i=0; i<customers.length; i++) {\n      assertEquals(\n        expStatement(\n          \"<h1>Rental record for \" +\n          \"<em>%s</em></h1>\\n%s\" +\n          \"<p>Amount owed is <em>%s</em>\" +\n          \"</p>\\n<p>You earned <em>%s\" +\n          \" frequent renter points</em></p>\",\n          customers[i],\n          rentalInfo(\n            \"<p>\", \"</p>\",\n            customers[i].getRentals())),\n        customers[i].htmlStatement());\n    }\n  }\n\n  @Test\n  (expected=IllegalArgumentException.class)\n  public void invalidTitle() {\n    ObjectMother\n      .customerWithNoRentals(\"Bob\")\n      .addRental(\n        new Rental(\n          new Movie(\"Crazy, Stupid, Love.\",\n                    Movie.Type.UNKNOWN),\n          4));\n  }\n

\n\n

  public static String rentalInfo(\n    String startsWith,\n    String endsWith,\n    List<Rental> rentals) {\n    String result = \"\";\n    for (Rental rental : rentals)\n      result += String.format(\n        \"%s%s\\t%s%s\\n\",\n        startsWith,\n        rental.getMovie().getTitle(),\n        rental.getCharge(),\n        endsWith);\n    return result;\n  }\n\n  public static String expStatement(\n    String formatStr,\n    Customer customer,\n    String rentalInfo) {\n    return String.format(\n      formatStr,\n      customer.getName(),\n      rentalInfo,\n      customer.getTotalCharge(),\n      customer.getTotalPoints());\n  }\n}\n

\n\n

The CustomerTest class completely covers our Customer domain object and has very little\nduplication; many would consider this a well written set of tests.

\n\n

As you can see, we’re using an ObjectMother to create our domain objects. The following code\nrepresents the full definition of our ObjectMother class.

\n\n

public class ObjectMother {\n  public static Customer\n  customerWithOneOfEachRentalType(\n    String name) {\n    Customer result =\n      customerWithOneNewReleaseAndOneRegular(\n        name);\n    result.addRental(\n      new Rental(\n        new Movie(\"Lion King\", CHILDREN), 3));\n    return result;\n  }\n\n  public static Customer\n  customerWithOneNewReleaseAndOneRegular(\n    String n) {\n    Customer result =\n      customerWithOneNewRelease(n);\n    result.addRental(\n      new Rental(\n        new Movie(\"Scarface\", REGULAR), 3));\n    return result;\n  }\n

\n\n

  public static Customer\n  customerWithOneNewRelease(\n    String name) {\n    Customer result =\n      customerWithNoRentals(name);\n    result.addRental(\n      new Rental(\n        new Movie(\n          \"Godfather 4\", NEW_RELEASE), 3));\n    return result;\n  }\n\n  public static Customer\n  customerWithNoRentals(String name) {\n    return new Customer(name);\n  }\n}\n

\n\n

Thoughts on our Tests

\n\n

Our CustomerTest class is written in a way that follows many common patterns. It\ndoesn’t take much searching on the Web to find articles giving examples of “improving”\nyour code by using a Setup (now @Before in JUnit). ObjectMother lives under many names,\nand each name comes with several articles explaining how it’s either successful or the\nprogrammer didn’t understand how to correctly apply the pattern. Our tests follow\nthe common advice that above all, code must be DRY.

\n\n

\n
DRY is an acronym for Don’t Repeat Yourself, and is defined as: Every piece\nof knowledge must have a single, unambiguous, authoritative representation\nwithin a system.
\n

\n\n

Both of those pieces of advice are contextually valuable. I can easily think of situations\nwhere applying each of those patterns would be the right choice. However, in the context of\n“I would like to quickly understand this test I’ve never seen before”, those patterns come\nup short. While working on code written by a teammate or supporting an inherited\nsystem, I find myself in the latter context far more often than not.

\n\n

I suspect most people will have skimmed the above tests - that’s what I would have\ndone. Other people may have taken the time to try to understand the test and how it relates\nto the failure output. If you’re in the second group, I suspect your thought process might\nhave looked something like this.

\n\n

find the statement test
find the definition of the customers array that we’re iterating
find the assignment to customers\n
digest the assignment of each Customer and their associated name
look to ObjectMother to determine how the Customer instances are created
digest each of the different Customer instance creation methods within the ObjectMother\n
- you now understand the first line of the test
\n
digest that the expected value is being created by calling a method with a String,\na Customer, and the result of calling rentalInfo with 2 String instances and a\ncustomer’s rentals.
find the rentalInfo method and determine what value it’s returning to expStatement\n
digest that rentalInfo is creating a string by iterating and formatting Rental data
now that you’ve mentally resolved the args to expStatement, you find that method and\ndigest it.\n
- at this point it’s taken 10 steps to simply understand the expected value in your test
\n
recognize that the actual value is a call to the domain object, who’s source I haven’t\nsupplied (yet).

That’s quite a bit you needed to digest, and all of it test code. Not one character\nof what you’ve digested will actually run in production.

\n\n

Were you actually trying to fix this test, the next logical question would be: which is\nincorrect, the expected value or the actual value? Unfortunately, before you could even\nbegin to tackle that question you’d need to find out what the expected and actual values\nactually are. We can see the text differs around the word “Godfather”, but that only narrows\nour list down to the customers john, steve, and pat. It’s practically\nimpossible to fix this test without writing some code and/or using the\ndebugger for runtime inspection to help you identify the issue.

\n\n

The Domain Code

\n\n

Below you will find the domain code from Refactoring rewritten\nfor Java 7. It’s not necessary to digest the domain code now to\ncomplete this chapter. I would recommend skimming or completely\nskipping to the end of the section, and coming back to use this\nas a reference only if you want to verify your understanding of\nthe code under test.

\n\n

public class Customer {\n\n  private String name;\n  private List<Rental> rentals =\n    new ArrayList<Rental>();\n\n  public Customer(String name) {\n    this.name = name;\n  }\n\n  public String getName() {\n    return name;\n  }\n\n  public List<Rental> getRentals() {\n    return rentals;\n  }\n\n  public void addRental(Rental rental) {\n    rentals.add(rental);\n  }\n

\n\n

  public String statement() {\n    String result =\n      \"Rental record for \" + getName() + \"\\n\";\n    for (Rental rental : rentals)\n      result +=\n        \"\\t\" + rental.getLineItem() + \"\\n\";\n    result +=\n      \"Amount owed is \" + getTotalCharge() +\n      \"\\n\" + \"You earned \" +\n      getTotalPoints() +\n      \" frequent renter points\";\n    return result;\n  }\n\n  public String htmlStatement() {\n    String result =\n      \"<h1>Rental record for <em>\" +\n      getName() + \"</em></h1>\\n\";\n    for (Rental rental : rentals)\n      result += \"<p>\" + rental.getLineItem() +\n        \"</p>\\n\";\n    result +=\n      \"<p>Amount owed is <em>\" +\n      getTotalCharge() + \"</em></p>\\n\" +\n      \"<p>You earned <em>\" +\n      getTotalPoints() +\n      \" frequent renter points</em></p>\";\n    return result;\n\n  }\n

\n\n

  public double getTotalCharge() {\n    double total = 0;\n    for (Rental rental : rentals)\n      total += rental.getCharge();\n    return total;\n  }\n\n  public int getTotalPoints() {\n    int total = 0;\n    for (Rental rental : rentals)\n      total += rental.getPoints();\n    return total;\n  }\n}\n

\n\n

public class Rental {\n\n  Movie movie;\n  private int daysRented;\n\n  public Rental(Movie movie, int daysRented) {\n    this.movie = movie;\n    this.daysRented = daysRented;\n  }\n\n  public Movie getMovie() {\n    return movie;\n  }\n\n  public int getDaysRented() {\n    return daysRented;\n  }\n\n  public double getCharge() {\n    return movie.getCharge(daysRented);\n  }\n\n  public int getPoints() {\n    return movie.getPoints(daysRented);\n  }\n\n  public String getLineItem() {\n    return\n      movie.getTitle() + \" \" + getCharge();\n  }\n}\n

\n\n

public class Movie {\n\n  public enum Type {\n    REGULAR, NEW_RELEASE, CHILDREN, UNKNOWN;\n  }\n\n  private String title;\n  Price price;\n\n  public Movie(\n    String title, Movie.Type priceCode) {\n    this.title = title;\n    setPriceCode(priceCode);\n  }\n\n  public String getTitle() {\n    return title;\n  }\n

\n\n

  private void setPriceCode(\n    Movie.Type priceCode) {\n    switch (priceCode) {\n    case CHILDREN:\n      price = new ChildrensPrice();\n      break;\n    case NEW_RELEASE:\n      price = new NewReleasePrice();\n      break;\n    case REGULAR:\n      price = new RegularPrice();\n      break;\n    default:\n      throw new IllegalArgumentException(\n        \"invalid price code\");\n    }\n  }\n\n  public double getCharge(int daysRented) {\n    return price.getCharge(daysRented);\n  }\n\n  public int getPoints(int daysRented) {\n    return price.getPoints(daysRented);\n  }\n}\n

\n\n

public abstract class Price {\n  abstract double getCharge(int daysRented);\n\n  int getPoints(int daysRented) {\n    return 1;\n  }\n}\n

\n\n

public class ChildrensPrice extends Price {\n  @Override\n  double getCharge(int daysRented) {\n    double amount = 1.5;\n    if (daysRented > 3)\n      amount += (daysRented - 3) * 1.5;\n    return amount;\n  }\n}\n

\n\n

public class RegularPrice extends Price {\n  @Override\n  public double getCharge(int daysRented) {\n    double amount = 2;\n    if (daysRented > 2)\n      amount += (daysRented - 2) * 1.5;\n    return amount;\n  }\n}\n

\n\n

public class NewReleasePrice extends Price {\n  @Override\n  public double getCharge(int daysRented) {\n    return daysRented * 3;\n  }\n\n  @Override\n  int getPoints(int daysRented) {\n    if (daysRented > 1)\n      return 2;\n    return 1;\n  }\n}\n

\n\n

Moving Towards Readability

\n\n

When asked “Why do you test?”, industry veteran Josh Graham gave the following answer:

\n\n

\n
To create a tiny universe where the software exists to do one thing and do it well.
\n

\n\n

The example tests could have been written for many reasons, let’s assume the motivators\nthat matter to us are: enable refactoring, immediate feedback, and breaking a problem up\ninto smaller pieces. The tests fit well for our first two motivators,\nbut fail to do a good job of breaking a problem up into smaller pieces. When\nwriting these tests it’s obvious and clear where “duplication” lies and how “common”\npieces can be pulled into helper methods. Unfortunately, each time we extract a method\nwe risk complicating our tiny universes. The right abstractions can reduce\ncomplexity; however, it’s often unclear which abstraction within\na test will provide the most value to the team.

\n\n

DRY has been applied to the tests as it would be to production code. At first glance this\nmay seem like a reasonable approach; however, test code and production code\nis written, maintained, and reviewed in drastically different ways.\nProduction code collaborates to provide a single running application,\nand it’s generally wise to avoid duplicating concepts within that application.\nTests do not, or at least should not collaborate; it’s\nuniversally accepted that inter-test dependency is an anti-pattern.\nIf we think of tests as tiny, independent universes, then code that appears\nin one test should not necessarily be\nconsidered inadvisable duplication if it appears in another test as well.

\n\n

Still, I recognize that pragmatic removal of duplication can add to maintainability.\nThe examples that follow will address issues such as\nWe’ve grouped david, john, pat, & steve despite the fact that none of them interact\nwith each other in any way whatsoever\nnot by duplicating every character, but by introducing local and global patterns that I\nfind superior.

\n\n

When I think about the current state of the tests, I remember my colleague\nPat Farley describing some tests as having been made DRY with a blowtorch.

\n\n

Rather than viewing our tests as a single interconnected program,\nwe can shift our focus to viewing\neach test as a tiny universe; each test can be an individual procedural program that\nhas a single responsibility. If we want to keep our individual procedural programs as\ntiny universes, we’ll likely make many decisions differently.

\n\n

We won’t test diverse customers at the same time.
We won’t create diverse customers that have nothing to do with each other.
We won’t extract methods for a single string return value.
We’ll create data where we need it, not as part of a special framework method.

In general, I find applying DRY to a subset of tests to be an anti-pattern. Within a\nsingle test, DRY can often apply. Likewise, globally appropriate DRY application is\noften a good choice. However, once you start applying DRY at a test group level you\noften increase the complexity of your individual procedures where a local or\nglobal solution would have been superior.

\n\n

For those that enjoy acronyms, when writing tests you should prefer DAMP (Descriptive\nAnd Maintainable Procedures) to DRY.

\n\n

The remainder of the chapter will demonstrate the individual\nsteps we can take to create\ntests so small they become trivial to immediately understand.

\n\n

Replace Loop with Individual Tests

\n\n

The first step in moving to more readable tests is breaking the\niteration into individual tests. The following code provides the same regression\nprotection and immediate feedback as the original, while also explicitly giving us\nmore information: passing and failing assertions that may give additional\nclues as to where the problem exists.

\n\n

public class CustomerTest {\n  Customer john, steve, pat, david;\n  String johnName = \"John\",\n    steveName = \"Steve\",\n    patName = \"Pat\",\n    davidName = \"David\";\n  Customer[] customers;\n\n  @Before\n  public void setup() {\n    david = ObjectMother\n      .customerWithNoRentals(davidName);\n    john = ObjectMother\n      .customerWithOneNewRelease(johnName);\n    pat = ObjectMother\n      .customerWithOneOfEachRentalType(\n        patName);\n    steve = ObjectMother\n      .customerWithOneNewReleaseAndOneRegular(\n        steveName);\n    customers = new Customer[] {\n      david, john, steve, pat };\n  }\n

\n\n

  @Test\n  public void davidStatement() {\n    assertEquals(\n      expStatement(\n        \"Rental record for %s\\n%sAmount \" +\n        \"owed is %s\\nYou earned %s \" +\n        \"frequent renter points\",\n        david,\n        rentalInfo(\n          \"\\t\", \"\", david.getRentals())),\n      david.statement());\n  }\n\n  @Test\n  public void johnStatement() {\n    assertEquals(\n      expStatement(\n        \"Rental record for %s\\n%sAmount \" +\n        \"owed is %s\\nYou earned %s \" +\n        \"frequent renter points\",\n        john,\n        rentalInfo(\n          \"\\t\", \"\", john.getRentals())),\n      john.statement());\n  }\n

\n\n

  @Test\n  public void patStatement() {\n    assertEquals(\n      expStatement(\n        \"Rental record for %s\\n%sAmount \" +\n        \"owed is %s\\nYou earned %s \" +\n        \"frequent renter points\",\n        pat,\n        rentalInfo(\n          \"\\t\", \"\", pat.getRentals())),\n      pat.statement());\n  }\n\n  @Test\n  public void steveStatement() {\n    assertEquals(\n      expStatement(\n        \"Rental record for %s\\n%s\" +\n        \"Amount owed is %s\\nYou earned %s \" +\n        \"frequent renter points\",\n        steve,\n        rentalInfo(\n          \"\\t\", \"\", steve.getRentals())),\n      steve.statement());\n  }\n

\n\n

  public static String rentalInfo(\n    String startsWith,\n    String endsWith,\n    List<Rental> rentals) {\n    String result = \"\";\n    for (Rental rental : rentals)\n      result += String.format(\n        \"%s%s\\t%s%s\\n\",\n        startsWith,\n        rental.getMovie().getTitle(),\n        rental.getCharge(),\n        endsWith);\n    return result;\n  }\n\n  public static String expStatement(\n    String formatStr,\n    Customer customer,\n    String rentalInfo) {\n    return String.format(\n      formatStr,\n      customer.getName(),\n      rentalInfo,\n      customer.getTotalCharge(),\n      customer.getTotalPoints());\n  }\n}\n

\n\n

The following output is the result of running the above test.

\n\n

JUnit version 4.11\n.E.E..E\nThere were 3 failures:\n1) johnStatement(CustomerTest)\norg.junit.ComparisonFailure: expected:<...or John\n\tGodfather 4[\t]9.0\nAmount owed is 9...> but was:<...or John\n\tGodfather 4[ ]9.0\nAmount owed is 9...>\n2) steveStatement(CustomerTest)\norg.junit.ComparisonFailure: expected:<...r Steve\n\tGodfather 4[\t9.0\n\tScarface\t]3.5\nAmount owed is 1...> but was:<...r Steve\n\tGodfather 4[ 9.0\n\tScarface ]3.5\nAmount owed is 1...>\n3) patStatement(CustomerTest)\norg.junit.ComparisonFailure: expected:<...for Pat\n\tGodfather 4[\t9.0\n\tScarface\t3.5\n\tLion King\t]1.5\nAmount owed is 1...> but was:<...for Pat\n\tGodfather 4[ 9.0\n\tScarface 3.5\n\tLion King ]1.5\nAmount owed is 1...>\n\nFAILURES!!!\nTests run: 4,  Failures: 3\n

\n\n

At this point we have more clues about which tests are failing and where; specifically,\nwe know that davidStatement is passing, so the issue must exist in the printing of rental\ninformation. Unfortunately, we don’t currently have any strings to quickly look at to\ndetermine whether the error exists in our expected or actual values.

\n\n

Expect Literals

\n\n

The next step in increasing readability is expecting literal values. If you know where\nthe problem exists, having DRY tests can help ensure you type the fewest number of characters.\nThat said…

\n\n

\n
“Programming is not about typing… it’s about thinking.”\n–Rich Hickey
\n

\n\n

At this point, our tests have become much smaller universes, so small that I find myself\nwondering why I call a parameterized method, once, that does nothing more than return a String.\nWithin my tiny universe it would be much easier to simply use a String literal.

\n\n

A few printlns and copy-pastes later, my tests are much more explicit, and my universes\nhave gotten even smaller.

\n\n

public class CustomerTest {\n  Customer john, steve, pat, david;\n  String johnName = \"John\",\n    steveName = \"Steve\",\n    patName = \"Pat\",\n    davidName = \"David\";\n  Customer[] customers;\n\n  @Before\n  public void setup() {\n    david = ObjectMother\n      .customerWithNoRentals(davidName);\n    john = ObjectMother\n      .customerWithOneNewRelease(johnName);\n    pat = ObjectMother\n      .customerWithOneOfEachRentalType(\n        patName);\n    steve = ObjectMother\n      .customerWithOneNewReleaseAndOneRegular(\n        steveName);\n    customers = new Customer[] {\n      david, john, steve, pat };\n  }\n\n  @Test\n  public void davidStatement() {\n    assertEquals(\n      \"Rental record for David\\nAmount \" +\n      \"owed is 0.0\\n\" +\n      \"You earned 0 frequent renter points\",\n      david.statement());\n  }\n

\n\n

  @Test\n  public void johnStatement() {\n    assertEquals(\n      \"Rental record for John\\n\\t\" +\n      \"Godfather 4\\t9.0\\n\" +\n      \"Amount owed is 9.0\\n\" +\n      \"You earned 2 frequent renter points\",\n      john.statement());\n  }\n\n  @Test\n  public void patStatement() {\n    assertEquals(\n      \"Rental record for Pat\\n\\t\" +\n      \"Godfather 4\\t9.0\\n\" +\n      \"\\tScarface\\t3.5\\n\" +\n      \"\\tLion King\\t1.5\\n\" +\n      \"Amount owed is 14.0\\n\" +\n      \"You earned 4 frequent renter points\",\n      pat.statement());\n  }\n

\n\n

  @Test\n  public void steveStatement() {\n    assertEquals(\n      \"Rental record for Steve\\n\\t\" +\n      \"Godfather 4\\t9.0\\n\" +\n      \"\\tScarface\\t3.5\\n\" +\n      \"Amount owed is 12.5\\n\" +\n      \"You earned 3 frequent renter points\",\n      steve.statement());\n  }\n}\n

\n\n

The failure output is exactly the same, but I’m now able to look at the expected\nvalue as a simple constant, and reduce my first question to: is my expected value correct?\nFor those coding along: we’ll assume the “fix” for the failure is to change the\nexpected value to match the implementation in Rental.getLineItem (space delimited).\nThe expected values moving forward will reflect this fix.

\n\n

\n
note: Some reviewers were offended by the getRentals public method\n(though others were not). If a method such as getRentals is something you’d look\nto remove from your domain model, then the Expect Literals refactoring provides you\nwith at least two benefits: the one you’ve already seen, and the ability\nto delete the getRentals method entirely. These types of improvements\n(deleting code while also improving expressiveness\nis always an improvement, regardless of your preferred OO style) are\nnot uncommon; improving tests often allows you to improve your domain model as well.
\n

\n\n

There’s an entire section dedicated to Expect Literals in\nImproving Assertions

\n\n

If this were more than a book example, my next step would likely be adding\nfine grained tests that verify individual methods of each of the classes that\nare collaborating with Customer. Unfortunately, moving in that direction will\nfirst require discussion on the benefits of fine grained tests\nand the trade-offs of using mocks and stubs.

\n\n

If you’re interested in jumping straight to this discussion it can be found in the\nTypes of Tests chapter.

\n\n

Inline Setup

\n\n

At this point it should be easy to find the source of the failing test; however, our\nuniverses aren’t quite DAMP just yet.

\n\n

Have you ever stopped to ask yourself why we use a design pattern (Template Method)\nin our tests, when an explicit method call is probably the appropriate choice 99%\nof the time?

\n\n

Creating instances of david, john, pat, & steve in Setup moves characters out of\nthe individual test methods, but doesn’t provide us any other advantage. It also comes\nwith the conceptual overhead of each Customer being created, whether or not it’s used.\nBy adding a level of indirection we’ve removed characters from tests,\nbut we’ve forced ourselves to remember who has what rentals.\nRemoving a setup method almost always reveals an opportunity for a\nlocal or global improvement within a universe.

\n\n

In this case, by removing Setup we’re able to further limit the number of variables that\nrequire inspection when you first encounter a test. With Setup removed you no longer need\nto look for a Setup method, and you no longer need to care about the Customer instances\nthat are irrelevant to your tiny universe.

\n\n

public class CustomerTest {\n  @Test\n  public void noRentalsStatement() {\n    assertEquals(\n      \"Rental record for David\\nAmount \" +\n      \"owed is 0.0\\n\" +\n      \"You earned 0 frequent renter points\",\n      ObjectMother\n      .customerWithNoRentals(\n        \"David\").statement());\n  }\n\n  @Test\n  public void oneNewReleaseStatement() {\n    assertEquals(\n      \"Rental record for John\\n\\t\" +\n      \"Godfather 4 9.0\\n\" +\n      \"Amount owed is 9.0\\n\" +\n      \"You earned 2 frequent renter points\",\n      ObjectMother\n      .customerWithOneNewRelease(\n        \"John\").statement());\n  }\n

\n\n

  @Test\n  public void allRentalTypesStatement() {\n    assertEquals(\n      \"Rental record for Pat\\n\\t\" +\n      \"Godfather 4 9.0\\n\" +\n      \"\\tScarface 3.5\\n\\tLion King 1.5\\n\" +\n      \"Amount owed is 14.0\\n\" +\n      \"You earned 4 frequent renter points\",\n      ObjectMother\n      .customerWithOneOfEachRentalType(\n        \"Pat\").statement());\n  }\n\n  @Test\n  public void\n  newReleaseAndRegularStatement() {\n    assertEquals(\n      \"Rental record for Steve\\n\\t\" +\n      \"Godfather 4 9.0\\n\" +\n      \"\\tScarface 3.5\\n\" +\n      \"Amount owed is 12.5\\n\" +\n      \"You earned 3 frequent renter points\",\n      ObjectMother\n      .customerWithOneNewReleaseAndOneRegular(\n        \"Steve\").statement());\n  }\n}\n

\n\n

By Inlining Setup we get to delete both the Setup method and the Customer\nfields. Our tests are looking nice and slim, and they require almost no navigation to\ncompletely understand. I went ahead and renamed the tests, deleted the unused customers\nfield, and inlined the single usage fields.

\n\n

It’s confession time: I don’t like test names.\nTechnically they’re method names, but they’re never called explicitly. That alone should\nmake you somewhat suspicious. I consider method names found within tests to be\nglorified comments that come with all\nthe standard warnings: they often grow out of date, and are often\na Code Smell\nemanating from bad code. Unfortunately, most testing frameworks make test names mandatory,\nand you should spend the time to create helpful test names. While we refactored\naway from the looping test I lazily named my tests based on the customer; however, I\nwas forced to create a more appropriate name as a side effect of performing Inline Setup.

\n\n

I believe this is another example of how well written tests have side effects that improve\nassociated code. I’ve personally written testing frameworks that make test names optional,\nthat’s how little I care about test names. Still, once I performed Inline Setup, the only\nreasonable choice was to create a somewhat helpful test name.

\n\n

Our tests are looking better and better, and I’m feeling motivated to continue\nthe evolution. There’s still one additional step I would take.

\n\n

Replace ObjectMother with DataBuilder

\n\n

ObjectMother is an effective tool when the scenarios are limited and constant, but there’s\nno clear way to handle the situation when you need a slightly different scenario. For example,\nif you wanted to create a test for the statement method on a Customer with two New\nReleases, would you add another ObjectMother method or would you call the addRental method\non an instance returned?

\n\n

Further complicating the issue: it’s often hard to know if you’re\ndealing with objects that you can manipulate or if the objects returned\nfrom an ObjectMother are reused. For example, if you called\nObjectMother.customerWithTwoNewReleases, can you change the name on one of the New Release\ninstances, or was the same Movie supplied to addRental twice? You can’t know without\nlooking at the implementation.

\n\n

At this point it would be natural to delete the ObjectMother and simply create your\ndomain model instances using new. If the number of calls to new within your tests will\nbe limited, that’s the pragmatic path. However, as the number of calls to new grows\nso does the risk of needing to do a cascading update. Say you have less than a dozen\ncalls to new Customer(...) in your tests and you need to add a constructor argument,\nupdating those dozen or less calls will not severely impact your effectiveness. Conversely,\nif you have one hundred calls to new Customer(...) and you add a constructor\nargument, you’re now forced to update the code in one hundred different places.

\n\n

A DataBuilder is an alternative to a scenario based ObjectMother that also\naddresses the cascading update risk. The following a class is a DataBuilder\nthat will allow us to build\nour domain objects that aren’t tied to any particular scenario.

\n\n

(I recommend skimming the following builder, we’ll revisit Test Data Builders\nin detail in the TestDataBuilder section of Chapter 6)

\n\n

public class a {\n  public static CustomerBuilder customer =\n    new CustomerBuilder();\n  public static RentalBuilder rental =\n    new RentalBuilder();\n  public static MovieBuilder movie =\n    new MovieBuilder();\n\n  public static class CustomerBuilder {\n    Rental[] rentals;\n    String name;\n\n    CustomerBuilder() {\n      this(\"Jim\", new Rental[0]);\n    }\n\n    CustomerBuilder(\n      String name, Rental[] rentals) {\n      this.name = name;\n      this.rentals = rentals;\n    }\n\n    public CustomerBuilder w(\n      RentalBuilder... builders) {\n      Rental[] rentals =\n        new Rental[builders.length];\n      for (int i=0; i<builders.length; i++) {\n        rentals[i] = builders[i].build();\n      }\n      return\n        new CustomerBuilder(name, rentals);\n    }\n\n    public CustomerBuilder w(String name) {\n      return\n        new CustomerBuilder(name, rentals);\n    }\n\n    public Customer build() {\n      Customer result = new Customer(name);\n      for (Rental rental : rentals) {\n        result.addRental(rental);\n      }\n      return result;\n    }\n  }\n

\n\n

  public static class RentalBuilder {\n    final Movie movie;\n    final int days;\n\n    RentalBuilder() {\n      this(new MovieBuilder().build(), 3);\n    }\n\n    RentalBuilder(Movie movie, int days) {\n      this.movie = movie;\n      this.days = days;\n    }\n\n    public RentalBuilder w(\n      MovieBuilder movie) {\n      return\n        new RentalBuilder(\n          movie.build(), days);\n    }\n\n    public Rental build() {\n      return new Rental(movie, days);\n    }\n  }\n

\n\n

  public static class MovieBuilder {\n    final String name;\n    final Movie.Type type;\n\n    MovieBuilder() {\n      this(\"Godfather 4\",\n           Movie.Type.NEW_RELEASE);\n    }\n\n    MovieBuilder(\n      String name, Movie.Type type) {\n      this.name = name;\n      this.type = type;\n    }\n\n    public MovieBuilder w(Movie.Type type) {\n      return new MovieBuilder(name, type);\n    }\n\n    public MovieBuilder w(String name) {\n      return new MovieBuilder(name, type);\n    }\n\n    public Movie build() {\n      return new Movie(name, type);\n    }\n  }\n}\n

\n\n

The a class is undeniably longer than an ObjectMother; however it’s not only more\ngeneral it also puts the decision in your hands to share or not share an object. Let’s look\nat what our test could look like when utilizing a Test Data Builder.

\n\n

\n
note: w() is an abbreviation for with().
\n

\n\n

public class CustomerTest {\n  @Test\n  public void noRentalsStatement() {\n    assertEquals(\n      \"Rental record for David\\nAmount \" +\n      \"owed is 0.0\\nYou earned 0 frequent \" +\n      \"renter points\",\n      a.customer.w(\n        \"David\").build().statement());\n  }\n\n  @Test\n  public void oneNewReleaseStatement() {\n    assertEquals(\n      \"Rental record for John\\n\\t\" +\n      \"Godfather 4 9.0\\nAmount owed is \" +\n      \"9.0\\nYou earned 2 frequent renter \" +\n      \"points\",\n      a.customer.w(\"John\").w(\n        a.rental.w(\n          a.movie.w(NEW_RELEASE))).build()\n      .statement());\n  }\n

\n\n

  @Test\n  public void allRentalTypesStatement() {\n    assertEquals(\n      \"Rental record for Pat\\n\\t\" +\n      \"Godfather 4 9.0\\n\\tScarface 3.5\\n\" +\n      \"\\tLion King 1.5\\nAmount owed is \" +\n      \"14.0\\nYou earned 4 frequent renter \" +\n      \"points\",\n      a.customer.w(\"Pat\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(a.movie.w(\"Scarface\").w(\n                     REGULAR)),\n        a.rental.w(a.movie.w(\"Lion King\").w(\n                     CHILDREN))).build()\n      .statement());\n  }\n

\n\n

  @Test\n  public void\n  newReleaseAndRegularStatement() {\n    assertEquals(\n      \"Rental record for Steve\\n\\t\" +\n      \"Godfather 4 9.0\\n\\tScarface 3.5\\n\" +\n      \"Amount owed is 12.5\\nYou earned 3 \" +\n      \"frequent renter points\",\n      a.customer.w(\"Steve\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(\n          a.movie.w(\n            \"Scarface\").w(REGULAR))).build()\n      .statement());\n  }\n}\n

\n\n

The above test is functionally equivalent to\nall the previous test methods used to verify statement.\nThis version does require us to understand the abstract concept and concrete implementation\nof a Test Data Builder; however, there’s no guarantee that you would need to\nvisit the a class\nto understand this test - even the first time you encounter the test. The a class is a\nclass used globally to create all domain objects for all tests. With that kind of scope,\nunless this is your first day on a project, it’s not really possible that you wouldn’t have\nencountered the a class in the past.

\n\n

To be more clear, the lone responsibility of a Test Data Builder\nis to create domain objects with\ndefault values. Thus, even if you’ve never seen this test before, without navigating to\na you’ll already know that you’re creating a customer with sensible defaults. This\nis a rare example of an abstraction that, despite adding indirection, also\nmakes the test easier to digest.

\n\n

With a Test Data Builder in place it becomes trivial to add an\nadditional test that verifies the case of 2 New Releases, or any other rental\ncombination that you find to be important.

\n\n

As I previously mentioned, the choice to use a Test Data Builder will likely\ndepend on the number of calls to new and your tolerance for cascading update\nrisk. I introduce them here due to their frequent usage throughout the book. In\npractice I like to use new while there are half a dozen or fewer calls to a\nconstructor.

\n\n

More information on Test Data Builders can be found in\nNat Pryce’s article on Test Data Builders and by skipping\ndirectly to the TestDataBuilder section of Chapter 6.

\n\n

Comparing the Results

\n\n

\n
Any fool can write code that a computer can understand. Good programmers write\ncode that humans can understand.\n–Martin Fowler, Refactoring.
\n\n
Applied to Unit Testing: Any fool can write a test that helps them today. Good\nprogrammers write tests that help the entire team in the future.
\n

\n\n

Below you can find both the before and after examples, allowing a quick comparison.

\n\n

Original

\n\n

public class CustomerTest {\n  Customer john, steve, pat, david;\n  String johnName = \"John\",\n    steveName = \"Steve\",\n    patName = \"Pat\",\n    davidName = \"David\";\n  Customer[] customers;\n\n  @Before\n  public void setup() {\n    david = ObjectMother\n      .customerWithNoRentals(\n        davidName);\n    john = ObjectMother\n      .customerWithOneNewRelease(\n        johnName);\n    pat = ObjectMother\n      .customerWithOneOfEachRentalType(\n        patName);\n    steve = ObjectMother\n      .customerWithOneNewReleaseAndOneRegular(\n        steveName);\n    customers =\n      new Customer[]\n      { david, john, steve, pat};\n  }\n

\n\n

  @Test\n  public void getName() {\n    assertEquals(\n      davidName, david.getName());\n    assertEquals(\n      johnName, john.getName());\n    assertEquals(\n      steveName, steve.getName());\n    assertEquals(\n      patName, pat.getName());\n  }\n\n  @Test\n  public void statement() {\n    for (int i=0; i<customers.length; i++) {\n      assertEquals(\n        expStatement(\n          \"Rental record for %s\\n\" +\n          \"%sAmount owed is %s\\n\"  +\n          \"You earned %s frequent \" +\n          \"renter points\",\n          customers[i],\n          rentalInfo(\n            \"\\t\", \"\",\n            customers[i].getRentals())),\n        customers[i].statement());\n    }\n  }\n

\n\n

  @Test\n  public void htmlStatement() {\n    for (int i=0; i<customers.length; i++) {\n      assertEquals(\n        expStatement(\n          \"<h1>Rental record for \" +\n          \"<em>%s</em></h1>\\n%s\" +\n          \"<p>Amount owed is <em>%s</em>\" +\n          \"</p>\\n<p>You earned <em>%s\" +\n          \" frequent renter points</em></p>\",\n          customers[i],\n          rentalInfo(\n            \"<p>\", \"</p>\",\n            customers[i].getRentals())),\n        customers[i].htmlStatement());\n    }\n  }\n\n  @Test\n  (expected=IllegalArgumentException.class)\n  public void invalidTitle() {\n    ObjectMother\n      .customerWithNoRentals(\"Bob\")\n      .addRental(\n        new Rental(\n          new Movie(\"Crazy, Stupid, Love.\",\n                    Movie.Type.UNKNOWN),\n          4));\n  }\n

\n\n

  public static String rentalInfo(\n    String startsWith,\n    String endsWith,\n    List<Rental> rentals) {\n    String result = \"\";\n    for (Rental rental : rentals)\n      result += String.format(\n        \"%s%s\\t%s%s\\n\",\n        startsWith,\n        rental.getMovie().getTitle(),\n        rental.getCharge(),\n        endsWith);\n    return result;\n  }\n\n  public static String expStatement(\n    String formatStr,\n    Customer customer,\n    String rentalInfo) {\n    return String.format(\n      formatStr,\n      customer.getName(),\n      rentalInfo,\n      customer.getTotalCharge(),\n      customer.getTotalPoints());\n  }\n}\n

\n\n

Final

\n\n

public class CustomerTest {\n  @Test\n  public void getName() {\n    assertEquals(\n      \"John\",\n      a.customer.w(\n        \"John\").build().getName());\n  }\n\n  @Test\n  public void noRentalsStatement() {\n    assertEquals(\n      \"Rental record for David\\nAmount \" +\n      \"owed is 0.0\\nYou earned 0 frequent \" +\n      \"renter points\",\n      a.customer.w(\n        \"David\").build().statement());\n  }\n

\n\n

  @Test\n  public void oneNewReleaseStatement() {\n    assertEquals(\n      \"Rental record for John\\n\" +\n      \"\\tGodfather 4 9.0\\n\" +\n      \"Amount owed is 9.0\\n\" +\n      \"You earned 2 frequent renter points\",\n      a.customer.w(\"John\").w(\n        a.rental.w(\n          a.movie.w(\n            NEW_RELEASE))).build()\n      .statement());\n  }\n\n  @Test\n  public void allRentalTypesStatement() {\n    assertEquals(\n      \"Rental record for Pat\\n\" +\n      \"\\tGodfather 4 9.0\\n\" +\n      \"\\tScarface 3.5\\n\" +\n      \"\\tLion King 1.5\\n\" +\n      \"Amount owed is 14.0\\n\" +\n      \"You earned 4 frequent renter points\",\n      a.customer.w(\"Pat\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(\n          a.movie.w(\"Scarface\").w(REGULAR)),\n        a.rental.w(\n          a.movie.w(\"Lion King\").w(\n            CHILDREN))).build().statement());\n  }\n

\n\n

  @Test\n  public void\n  newReleaseAndRegularStatement() {\n    assertEquals(\n      \"Rental record for Steve\\n\" +\n      \"\\tGodfather 4 9.0\\n\" +\n      \"\\tScarface 3.5\\n\" +\n      \"Amount owed is 12.5\\n\" +\n      \"You earned 3 frequent renter points\",\n      a.customer.w(\"Steve\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(\n          a.movie.w(\"Scarface\").w(\n            REGULAR))).build().statement());\n  }\n\n  @Test\n  public void noRentalsHtmlStatement() {\n    assertEquals(\n      \"<h1>Rental record for <em>David\" +\n      \"</em></h1>\\n<p>Amount owed is <em>\" +\n      \"0.0</em></p>\\n<p>You earned <em>0 \" +\n      \"frequent renter points</em></p>\",\n      a.customer.w(\n        \"David\").build().htmlStatement());\n  }\n

\n\n

  @Test\n  public void oneNewReleaseHtmlStatement() {\n    assertEquals(\n      \"<h1>Rental record for <em>John</em>\" +\n      \"</h1>\\n<p>Godfather 4 9.0</p>\\n\" +\n      \"<p>Amount owed is <em>9.0</em></p>\" +\n      \"\\n<p>You earned <em>2 frequent \" +\n      \"renter points</em></p>\",\n      a.customer.w(\"John\").w(\n        a.rental.w(\n          a.movie.w(\n            NEW_RELEASE))).build()\n      .htmlStatement());\n  }\n

\n\n

  @Test\n  public void allRentalTypesHtmlStatement() {\n    assertEquals(\n      \"<h1>Rental record for <em>Pat</em>\" +\n      \"</h1>\\n<p>Godfather 4 9.0</p>\\n\" +\n      \"<p>Scarface 3.5</p>\\n<p>Lion King\" +\n      \" 1.5</p>\\n<p>Amount owed is <em>\" +\n      \"14.0</em></p>\\n<p>You earned <em>\" +\n      \"4 frequent renter points</em></p>\",\n      a.customer.w(\"Pat\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(\n          a.movie.w(\"Scarface\").w(REGULAR)),\n        a.rental.w(\n          a.movie.w(\"Lion King\").w(\n            CHILDREN))).build()\n      .htmlStatement());\n  }\n

\n\n

  @Test\n  public void\n  newReleaseAndRegularHtmlStatement() {\n    assertEquals(\n      \"<h1>Rental record for <em>Steve\" +\n      \"</em></h1>\\n<p>Godfather 4 9.0</p>\" +\n      \"\\n<p>Scarface 3.5</p>\\n<p>Amount \" +\n      \"owed is <em>12.5</em></p>\\n<p>\" +\n      \"You earned <em>3 frequent renter \" +\n      \"points</em></p>\",\n      a.customer.w(\"Steve\").w(\n        a.rental.w(a.movie.w(NEW_RELEASE)),\n        a.rental.w(\n          a.movie.w(\"Scarface\").w(\n            REGULAR))).build()\n      .htmlStatement());\n  }\n\n  @Test\n  (expected=IllegalArgumentException.class)\n  public void invalidTitle() {\n    a.customer.w(\n      a.rental.w(\n        a.movie.w(UNKNOWN))).build();\n  }\n}\n

\n\n

Final Thoughts on our Tests

\n\n

The tests in this chapter are fairly simple, and yet they still provide more than\nenough content to create discussion among most software engineers.

\n\n

Whether you prefer the original or final versions of CustomerTest, it’s undeniable that\nthe final version creates far tinier universes to work within. At this point you should\nhave a fairly deep understanding of this simple example. That hard won deep\nunderstanding can be misleading when assessing the relative merits of the two testing\napproaches. If you write tests assuming the same level\nof understanding, you force future maintainers to gain that understanding. Conversely,\nthe tests from the final example put all of the test data either directly in the test\nor in what should be a globally understood class.

\n\n

\n
The decision to write DRY or DAMP tests often comes down to whether or not you want to\nforce future maintainers to deeply understand code written strictly for testing purposes.
\n

\n\n

An interesting side note: despite replacing DRY tests with DAMP tests, the overall number\nof lines in the CustomerTest class barely changed.

\n\n

The ‘Final’ version of CustomerTest improved in a few\nsubtle ways that weren’t previously emphasized.

\n\n

A test that contains more than one assertion (or one assertion that lives in a loop) will\nterminate on the first failure. By breaking the iteration into individual tests\nwe were able to see all of the failures generated by our domain code change.
The invalidTitle test uses the same instance creation code that all of the other\nCustomer tests use. Now that all Customer, Rental, and Movie instances are created by a\nDataBuilder you can make constructor argument changes and the only consequence will be\nmaking a change to the build method for the associated *Builder class.

If you’re with me this far, it should be relatively clear what a DAMP test is, and\nthat I believe them to be far more valuable than DRY tests. From here we’ll drop a bit\ninto theory, then straight into deeper examples of how to evolve your tests towards\na DAMP style, and finally we’ll finish with test suite level improvements and\nwhat to avoid once you venture on to Broad Stack Tests.

\n\n

Motivators

\n\n

There are many ways to succeed while writing tests; however, let’s start with\nan example of the more common path.

\n\n

Let’s imagine you read Unit Testing Tips: Write Maintainable Unit Tests That Will Save\nYou Time And Tears and decide that Roy Osherove has shown you the light.\nYou’re going to write all your tests with Roy’s suggestions in mind. You get the entire\nteam to read Roy’s article and everyone adopts the patterns.

\n\n

Things are going well until you start accidentally breaking tests that someone else wrote\nand you can’t\nfigure out why. It turns out that some object created in the Setup\nmethod is causing unexpected failures due to a side-effect of your ‘minor’\nchange. You’re frustrated, having been burned by Setup, and you remember\nthe blog entry by Jim Newkirk where he discussed\nWhy you should not use SetUp and TearDown in NUnit.\nNow you’re stuck with a Setup heavy test suite, and a growing\nsuspicion that you’ve gone down the wrong path.

\n\n

You do more research on Setup and stumble upon\nInline Setup.\nYou can entirely relate and go on a mission to switch all the tests to xUnit.net;\nxUnit.net removes the concept of Setup entirely.

\n\n

Everything looks good initially, but then a few constructors start needing more\ndependencies. Every test creates an instance of an object; you moved the object\ncreation out of the Setup and into each individual test. So now every test that creates\nthat object needs to be updated. It becomes painful every time you add an argument to\na constructor. You’re once again left feeling like you’ve been burnt by following “expert”\nadvice.

\n\n

The root problem: you never asked yourself ‘why?’. Why are you writing\ntests in the first place? Each testing practice you’ve chosen, what motivated you to adopt it?

\n\n

You won’t write better software by blindly following advice. This is especially true\ngiven that much of the advice around testing is inconsistent or outright conflicting.\nWhile I’m writing this chapter\nthere’s currently a twitter discussion with Martin Fowler, Michael Feathers, Bob Martin,\nPrag Dave, and David Heinemeier Hansson (all well respected and successful software\nengineers) where there are drastically conflicting opinions on\nhow to effectively test. If there’s a universally right way, we haven’t\nfound it yet.

\n\n

\n
It’s worth noting that the articles from Roy and Jim are quite old.\nRoy has since changed his mind on Setup (his current opinions can be found at\nartofunittesting.com),\nand I’m sure Jim has updated his opinions as well.\nThe point of the example is to show how it’s easy to blindly follow advice that sounds good,\nnot to tie a good or bad idea with an individual.
\n

\n\n

Back to our painful journey above: your intentions were good. You want to write better\nsoftware, so you followed some\nreasonable advice. Unfortunately, the advice you’ve chosen to follow left you with\nmore pain than happiness. Your tests aren’t providing enough value to justify their effort\nand if you keep going down this path you’ll inevitably conclude that testing is stupid and\nit should be abandoned.

\n\n

If you’ve traveled the path above or if you aren’t regularly writing unit tests,\nyou may find yourself wondering why other developers\nfind them so essential. Ultimately I believe the answer boils down to selecting testing\npatterns based on what’s motivating you to test.

\n\n

The remainder of this chapter will focus on defining testing motivators.\nThe list that follows is presented unordered, and includes\nboth helpful and harmful motivators. Neither inclusion nor list index\nreflect the value of a motivator.

\n\n

Validate the System

\n\n

Common motivators that would be a subset of Validate the System

\n\n

Immediate Feedback That Things Work as Expected
Prevent Future Regressions

Static languages like Java provide a compiler that protects you from a\ncertain class of errors; however, unit tests often prove their value when you need to verify\nnot the type of a result, but the value of the result. For example, if your shopping cart\ncannot correctly calculate the total of each contained item, it won’t really matter that the\nresult is an Integer.

\n\n

For this reason, every codebase would benefit from, if nothing else,\nwrapping a few unit tests around the features of the system that if broken would cause\nthe system to become unusable.

\n\n

Theoretically, you could write a test to validate every feature of your system; however,\nI believe you would quickly find this task to be substantial and not necessarily worth\nyour time - certain features of your system will likely be more important than others.

\n\n

There’s a common term in finance: ROI

\n\n

\n
Return on investment (ROI) is the concept of an investment of some resource yielding a\nbenefit to the investor. A high ROI means the investment gains compare favorably to\ninvestment cost.
\n

\n\n

When I’m motivated to write a test to validate the system, I like to look at the test\nfrom an ROI point of view. My favorite example for demonstrating how I choose based on\nROI is the following:

\n\n

Given a system where customers are looked up exclusively by Social Security Number

\n\n

I would unit test that a Social Security Number is valid at account creation time
I would not unit test that a user’s name is alpha-numeric.

Losing a new account based on an invalid Social Security Number could be rather harmful\nto a business; however, storing an incorrect name for a limited amount of time should\nhave no impact on successful use of the system.

\n\n

As long as everyone on the team understands the ROI of the various features, you could\ntrust everyone to make the right call on when and when not to test based on ROI. If\nyour team cannot reasonably grant that responsibility and power to each team member then\nit will likely make sense to either pair program or err on the side of over testing and\nevaluating the ROI of each test during a code review.

\n\n

Tests written to validate the system are often used both to verify that the system\ncurrently works as expected as well as to prevent future regression.

\n\n

Code Coverage

\n\n

Automated code coverage metrics can be a wonderful thing when used correctly.\nUpon joining a project I\noften use code coverage to get a feel for the level of quality that I can expect from\nthe application code. A low coverage percentage can show probable lack of quality -\nthough I would consider it more of a hint than a guarantee. A high coverage percentage\nwould make me feel better about the likelihood of finding a well designed codebase, but\nthat’s also more of a hint than a guarantee.

\n\n

\n
I expect a high level of coverage. Sometimes managers require one.\nThere’s a subtle difference.\n–Brian Marick
\n

\n\n

I tend to agree with Martin Fowler’s view on the subject: If you are testing\nthoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s.\nI would be suspicious of anything like 100% - it would smell of someone writing\ntests to make the coverage numbers happy, but not thinking about what they are doing.

\n\n

Once upon a time a consultancy went as far as putting “100% code coverage” in their\ncontracts. It was a noble goal; unfortunately, a few years later the same consultancy\nwas presenting on the topic of: How to fail with 100% test coverage. There are various\nproblems with pushing towards 100%:

\n\n

You’ll have to test language features.
You’ll have to test framework features.
You’ll have to maintain a lot of tests with negative ROI.
etcetera

\n
I find that code coverage metrics over time may signal an interesting\nchange that you may have otherwise missed,\nbut as an absolute number, it’s not very useful. –John Hume
\n

\n\n

\n
My favorite “100% code coverage” story involves a team that added a bunch of tests\nto get to 100%… but didn’t add any assertions. Code coverage and verification\nare not the same thing. –Kent Spillner
\n

\n\n

I suspect most projects will suffer from the opposite, not enough coverage.\nThe good news is it’s quite simple to run a coverage tool and determine\nwhich pieces of code are untested.

\n\n

I’ve had success using EMMA and Clover, and John Hume recently pointed me\nto Cobertura. Code coverage tools are easy to work with; there’s no reason\nyou couldn’t try a few and decide which you prefer.

\n\n

Again, code coverage tools are great. I personally strive for around 80% coverage. If\nyou’re looking to get above 80%, it would not surprise me to find tests that have\ncode-coverage as their lone motivator.

\n\n

Enable Refactoring

\n\n

Getting test coverage on an untested codebase is always painful; however, it’s also\nessential if you’re planning to make any changes within the codebase. With the proper\ntests in place, you should be able to rewrite the internals of a codebase\nwithout breaking any of the existing contracts.

\n\n

In addition to helping you prevent regression, creating tests can also give you\ndirection on where the application can be logically broken up. While writing tests for a\ncodebase you should keep track of dependencies that need to be instantiated, mocked or\nstubbed but have nothing to do with the current functionality you are focusing on.\nIn general, these are the pieces that should be broken into components that are easily\nstubbed (ideally in 1 or 0 lines).

\n\n

Document the Behavior of the System

\n\n

When encountering a codebase for the first time, some developers go straight to the tests.\nThese developers read the tests, test names as well as method bodies, to determine the\nhow and why the system works as it does. These same developers enjoy the benefits of\nautomated tests, but they value the documentation of tests almost as much or more than\nthe functional aspect of the tests.

\n\n

It’s absolutely true that the code doesn’t lie, and both correct and incorrect comments\n(including test names) can often give a view into what a developer\nwas thinking when the test was\nwritten. If developers use tests as documentation, it’s only natural that they create\nmany tests, some of which would likely be unnecessary if they didn’t exist solely\nto document the system.

\n\n

Before you go deleting what appear to be superfluous tests, make sure you don’t have someone\non the team that sees your worthless test as essential documentation.

\n\n

Your Manager Told You To

\n\n

If this were your only motivator for writing a test, I think you’d be in a very\nparadoxical position. If you write worthless tests you’re sure to anger your manager.\nGiven that you’re forced to write “meaningful” tests, I believe you’d\nwant to write the most maintainable tests possible despite your lack of additional\nmotivators. I imagine that you’ll want to spend as little time as possible reading and\nwriting tests, and the only way I see accomplishing that is by focusing on maintainability.

\n\n

Thus, even if you don’t particularly value testing, it will likely benefit you to seek\nout the most maintainable way to write tests in your context.

\n\n

Test Driven Development

\n\n

Common motivators that would be a subset of TDD

\n\n

Breaking a Problem up into Smaller Pieces
Defining the “Simplest Thing that Could Possibly Work”
Improved Design

Unit Testing and TDD are often incorrectly conflated and referred to by either name. Unit\ntesting is an umbrella name for testing at a certain level of abstraction.\nTDD has a very specific definition:

\n\n

\n
Test-driven development (TDD) is a software development process that relies on the\nrepetition of a very short development cycle: first the developer writes an (initially\nfailing) automated test case that defines a desired improvement or new function, then\nproduces the minimum amount of code to pass that test, and finally refactors the new\ncode to acceptable standards.\n–Wikipedia
\n

\n\n

It’s not necessary to write unit tests to TDD, nor is it necessary to TDD to write unit\ntests.

\n\n

That said, there’s a reason that the terms are often conflated: If you’re practicing\nTDD, then you’re very likely also writing a substantial amount of unit tests. A codebase\nwritten by developers dogmatically following TDD would theoretically contain no code that\nwasn’t written as a result of a failing test. Proponents of TDD often claim that\nthe results of TDD give the existing team and future maintainers a greater level\nof confidence.

\n\n

TDD’s development cycle is also very appealing to developers who can find a large\nproblem overwhelming, but are able to quickly break a large problem down into\nmany smaller tests that, when combined, solve the larger problem. Rather than focusing\non the single large problem and trying to write code that solves for every known problem, the\ndevelopers will focus on writing tests for each individual variable and growing the code\nin a way where each test keeps passing and each variable is dealt with individually.

\n\n

Incredibly large and complicated problems don’t seem nearly as daunting when programmers\nare able to focus exclusively on the task at hand: make the individual test pass.\nIn addition, all of the previously written tests provide a safety net, thus allowing you\nto (harmlessly) ignore all prior constraints.

\n\n

Proponents of TDD generally believe it promotes superior design as well. Two\nreasons are the most often used when describing the design benefits of TDD:

\n\n

By focusing on the test cases first, a developer is forced to imagine how the functionality\nwill be used by clients.
TDD leads to more modularized, flexible, and extensible code by requiring that the\ndevelopers think of the software in terms of small units that can be written and\ntested independently and integrated together later.

In my opinion every developer should practice TDD at some point in their career. Utilizing TDD\nat the right moment will unquestionably make you more productive. That said, the frequency\nof those moments often depends greatly on the individual. Only through experience can a\ndeveloper know how to judge whether the current moment would benefit or suffer from switching\nto a TDD cycle.

\n\n

An anonymous comment once appeared on my blog:

\n\n

\n
The developers that know how to write tests correctly are very rare,\nand only those developers can really do TDD. The rest end up with a\nnest of poorly written brittle tests that don’t fully test the code.
\n

\n\n

It’s my hope that this book will help increase the number of developers that are\nproductively unit testing. Still, it’s perfectly reasonable to delete a test\nthat provided value as part of a TDD cycle, but no longer has positive ROI.

\n\n

Customer Acceptance

\n\n

Unit Testing to achieve customer acceptance would be an interesting choice. Rarely would\na domain expert be willing to sift through all of the unit tests to determine whether or\nnot they’re willing to sign off on the system. Thus, I imagine you’d need to devise some\ntype of filtering that allowed the domain expert to drill down to what they believed to\nbe important.

\n\n

My default choice is to enable the domain expert to write and maintain tests in a tool\ndesigned for high level tests; removing developers and unit tests almost entirely from\nthe acceptance process. However, if the developers must be responsible for\nwriting the tests used for customer acceptance, I would devise a plan to annotate the\nappropriate unit tests and provide a well formatted report based on the automated results.

\n\n

In my experience, developers are willing to support customer acceptance low level tests that\ncan quickly be debugged when they fail. Conversely, I’ve never seen a developer that was\nhappy to maintain tests that are both strictly for the customer and high level (thus hard\nto debug).

\n\n

Ping Pong Pair-Programming

\n\n

From the c2.com Wiki

\n\n

\n
here’s how Pair Programming works on my team.
\n\n
\n
A writes a new test and sees that it fails.
\n
B implements the code needed to pass the test.
\n
B writes the next test and sees that it fails.
\n
A implements the code needed to pass the test.
\n
\n
And so on.
\n

\n\n

While the most popular definition obviously describes a TDD approach, there’s no reason\nyou couldn’t ping-pong writing the test after. If you’re already pair programming, the\nrhythm created by practicing ping-pong may be the only motivator you need for writing a\ntest. I’ve seen this approach utilized very successfully.

\n\n

Once a feature is complete it’s often worth your time to examine the associated tests.\nMany of the recently created tests will be valuable as is. Other tests may\nprovide negative ROI as written,\nbut with small tweaks can be made to produce positive ROI.\nFinally, any tests that were motivated solely by the development process should be\nconsidered for deletion.

\n\n

What Motivates You (or Your Team)

\n\n

The primary driver for this chapter is to recognize that tests can be written for\nmany different reasons, and assuming that a test is necessary simply because it\nexists is not always the right decision. It’s valuable to recognize which\nmotivators are responsible for a test that you’re creating or updating. If you come\nacross a test with no motivators, do everyone a favor and delete the test.

\n\n

I often write speculative tests that help me get to feature\ncompletion, but are unnecessary in the long term. Those are the\ntests that I look to delete once a feature is complete. They’re\nvaluable to me for brainstorming purposes, but aren’t well designed\nfor documentation, regression detection, or any other motivator.\nOnce they’ve served their purpose, I happily kill them off.

\n\n

Deleting tests that no longer provide value is an important activity; however,\ndeleting tests is an activity that shouldn’t be taken lightly. Each test deletion\nlikely requires at least a little collaboration to ensure that (as I previously\nmentioned) your valueless test isn’t someone else’s documentation.

\n\n

More…

\n\n

buy now: https://leanpub.com/wewut

\n\n

join the discussion group (free): http://group.wewut.com

\n\n","tocStructure",[153,154,155,156,157,158,159,160,161,162,163,164,165,166,167],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_43":85,"_70":-5,"_78":86,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_43":89,"_70":-5,"_78":90,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_43":93,"_70":-5,"_78":94,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":98,"_70":-5,"_78":99,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":103,"_70":-5,"_78":104,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":106,"_70":-5,"_78":107,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":109,"_70":-5,"_78":110,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":112,"_70":-5,"_78":113,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":115,"_70":-5,"_78":116,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":118,"_70":-5,"_78":119,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":121,"_70":-5,"_78":122,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_43":124,"_70":-5,"_78":125,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_43":127,"_70":-5,"_78":128,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_43":131,"_70":-5,"_78":132,"_71":80,"_100":-5,"_101":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

More…

Table of Contents

Foreword

Preface

Why Test?

Who Should Read This Book

Building on the Foundations Laid by Others

Acknowledgments

Unit Testing, a First Example

Thoughts on our Tests

The Domain Code

Moving Towards Readability

Replace Loop with Individual Tests

Expect Literals

Inline Setup

Replace ObjectMother with DataBuilder

Comparing the Results

Original

Final

Final Thoughts on our Tests

Motivators

Validate the System

Common motivators that would be a subset of Validate the System

Code Coverage

Enable Refactoring

Document the Behavior of the System

Your Manager Told You To

Test Driven Development

Common motivators that would be a subset of TDD

Customer Acceptance

Ping Pong Pair-Programming

What Motivates You (or Your Team)

More…