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.