Chapter 6: Programmer Tests: Using TDD with ASP.NET Web Services

In this chapter, we demonstrate how to write programmer tests when implementing a Web service in ASP.NET. To illustrate the issues, we will build on the functionality we implemented in Chapter 5, Programmer Tests: Using TDD with ADO.NET to provide a Web service interface to the recording database. By the end of this chapter, you should have an understanding of the issues involved in writing tests that have to execute inside ASP.NET, how to use the service interface pattern (see Enterprise Solution Patterns in .NET from Microsoft Corporation, 2003) to separate the protocol-specific aspects of the Web service from your application s functionality, and how to use stub classes to isolate portions of your application for improved testability.

The Task

The task is to implement a Web service that returns a Recording and all its associated entities (Tracks, Reviews, and so on) when specifying the id of the recording. The return type of the service needs to be in a format that is not dependent on the .NET Framework. The Catalog class that we implemented in the previous chapter returns a typed DataSet named RecordingDataSet.Recording , which is specific to the .NET Framework and directly coupled to the database schema. Therefore, we need to write some code that takes as input the typed DataSet and transforms it into a data structure that can interoperate with other systems.

A data structure like this is called a data transfer object ^[1] (DTO), which is one aspect of the Web service implementation. Another aspect is the communication protocol that exists between the provider of the service and the consumer. ASP.NET Web services provide the necessary plumbing to implement the communication protocol. The combination of the communication protocol and DTO is a design pattern called service interface. It is very useful to keep the service interface code separate from the rest of the application s functionality because the intent of the code is very different.

Test List

You need to complete the following tasks :

• Build an in-memory representation of a RecordingDataSet , map it into a DTO, and verify each field. This allows us to test the data transformation separate from the database and the Web service.

• Retrieve a RecordingDataSet from the database, map it into the DTO, and verify the fields. This is a partial integration test of the database and the service interface code. These tests are not dependent on the Web service.

• Retrieve a RecordingDataSet using the Web service interface and verify the fields. This will test the Web service in its entirety.

Why three different types of tests? We want to be able to use failing programmer tests to pinpoint a problem in the code. Because of the dependencies that exist in the code, it can be difficult to know where the problem is. We want to write our programmer tests in a way that minimizes the dependencies. For example, suppose that there is a failing programmer test in the Web service and no other failing tests. Because the problem manifests itself only in the Web service implementation, the problem is likely there. Having this isolation reduces the time spent debugging. The downside is that it will take some time and effort to achieve this isolation.

At the end of the chapter, we will review the overhead involved and let you be the judge about the value. For now, let s get started with the tests for data transformation.

^[1] Martin Fowler, Patterns of Enterprise Application Architecture, Boston: Addison-Wesley, 2003.