Chapter 9: Driving Development with Customer Tests: Exposing a Failure Condition

Overview

In the previous chapter, we defined a customer test for adding and deleting a review from the database and then built the implementation accordingly. In this chapter, we enhance the AddReview Web service to prevent a reviewer from submitting multiple reviews for the same recording. When a reviewer attempts to do this, the Web service should not add the review to the database; it should return the id of the review that already exists in the database. Here is this requirement expressed as a customer test:

fit.ActionFixture
start	CustomerTests.ReviewAdapter	�
enter	FindByRecordingId	100001
enter	SetRating	4
enter	SetContent	Test Fit Content
enter	SetReviewerName	Example Reviewer
enter	AddReview	�
check	ReviewAdded	False
check	ExistingReviewId	100002

To run this script, we need to add a method, named ExistingReviewId, to the ReviewAdapter. For now, let’s fake the implementation and have the method always return 0. Let’s run the script and see if we get the failures that we anticipate. Here is the output of the script:

fit.ActionFixture
start	CustomerTests.ReviewAdapter	�
enter	FindByRecordingId	100001
enter	SetRating	4
enter	SetContent	Test Fit Content
enter	SetReviewerName	Example Reviewer
enter	AddReview	�
check	ReviewAdded	False expected
�	�	True actual
check	ExistingReviewId	100002 expected
�	�	0 actual

The script fails as anticipated because there is nothing in the implementation that prevents the user from adding a review to a recording as many times as he likes. In turn, we also run the programmer tests. Because all the programmer tests pass, there must be a missing programmer test. Let’s write a programmer test that exposes the problem and drives the implementation.