Reconciling Viewpoints

The first thing to do is to verify that the test and the test data are correct. In this case, the customer verified that both are correct, so the problem is with the software. We need to fix the software to pass the customer tests. One thing that needs to be pointed out is the process that will be used to fix these problems. Because we do not have a failing programmer test, it is clear that the programmers have misinterpreted the requirements in some way. To make sure that the programmer tests are in sync with the customer tests, we need to have at least one failing programmer test before we modify the code.

There are several reasons why we begin with a programmer test in such a case. First of all, the customer tests are usually too general to point to a specific problem spot in the code. Second, the failing customer test indicates a misunderstanding or a change in the user requirements, and we want to be able to use the programmer tests as a code-level requirement specification mechanism. So the programmer tests must be updated to reflect the change in the requirements. The failing customer tests that exist at this point are related to track and recording duration. We will address them one at a time.

Track Duration

Looking at the results, the track s duration is expected to be a string with the format min:sec, and we get an integer value representing the duration in seconds. Doing a quick calculation, we see that the number is correct; it is just not formatted in the correct way. We need to convert from seconds to min:sec to meet the customer requirements. The simplest thing we can do to make the test pass is to modify the Duration method of TrackDisplayAdapter . After making this change, the customer tests pass, but we are left with the feeling that this conversion does not belong in the TrackDisplayAdapter . As stated previously, this class is supposed to be a very simple adapter with no logic present. Having added the application-specific logic to this class, we violated this requirement: this code cannot be present in the adapter. So let s find the right place.

To correctly follow our process, we first remove the conversion code from the adapter and run the customer tests. They now fail the same way they did before. We need to write a programmer test that exposes the problem revealed by the failing customer tests. The problem is on the server side when the TrackDto is converted from the Track row. Let s write a programmer test in TrackAssemblerFixture to confirm this suspicion:

 [Test]    public void Duration()    {       Assert.AreEqual("1:40", trackDto.duration);    } 

This test fails, and we think this is the right place to address this problem because the RecordingAssembler should be responsible for the conversion of the Track s duration. Let s add the conversion code to the RecordingAssembler s WriteTrack method. When we try to do that, we come across another problem: TrackDto has duration defined as int, not a string. This means that we need to make changes to the Recording.xsd schema file and regenerate the data transfer objects. When this process is complete, the WriteTrack method looks like this:

 public static TrackDto WriteTrack(RecordingDataSet.Track track)    {                TrackDto trackDto = new TrackDto();                    trackDto.id = track.Id;       trackDto.title = track.Title;                 int minutes = track.Duration / 60;       int seconds = track.Duration % 60;        trackDto.duration = String.Format("{0}:{1}",          minutes, seconds.ToString("00"));                 trackDto.genreName = track.Genre.Name;       trackDto.artistName = track.Artist.Name;              return trackDto;    } 

We recompile and run all the programmer tests, and they succeed. In addition, we also run the customer tests. The ones associated with TrackDuration now pass. We weren t lucky enough with the Recording duration, so let s fix that now.

Recording Duration

The recording duration problem seems very similar to the problem with the Track s duration. So let s do the following:

• Modify the totalRunTime test in the RecordingAssemblerFixture to expect 3:20 instead of 200 .

• Modify Recording.xsd schema file by changing the type of the totalRunTime from int to string .

• Add the formatting code to the RecordingAssembler .

After we made these changes, all the programmer tests pass, and all the customer tests pass. We did introduce a small code duplication related to formatting the duration strings in the RecordingAssembler . We ll leave removing it as an exercise for you.