Database Catalog Service

In the previous section, we could isolate the tests and implementation from the database, which means that if we have a failing database test, it will not cascade into the tests for the RecordingAssembler . Now that we know that the code works in isolation, we need to hook up the code to the database so we can verify that the code on the server works correctly without the Web service. The first test is the CheckId test:

 [TestFixture] public class DatabaseCatalogServiceFixture : RecordingFixture  {    private DatabaseCatalogService service;     private RecordingDto dto;     [SetUp]    public new void SetUp()    {       base.SetUp();       service = new DatabaseCatalogService();       dto = service.FindByRecordingId(Recording.Id);    }    [Test]    public void CheckId()    {       Assert.AreEqual(Recording.Id, dto.id);    } } 

Although this code looks very similar to the CatalogServiceStubFixture , there are two big differences. First, the DatabaseCatalogServiceFixture inherits from RecordingFixture to insert Recording entities into the database. Second, we use a new class, DatabaseCatalogService , to retrieve the Recording from the database instead of using the CatalogServiceStub . Let s take a look at DatabaseCatalogService :

 public class DatabaseCatalogService {    public RecordingDto FindByRecordingId(long id)    {       RecordingDataSet dataSet = new RecordingDataSet();       RecordingDataSet.Recording recording =           Catalog.FindByRecordingId(dataSet, id);       if(recording == null) return null;       return RecordingAssembler.WriteDto(recording);    } } 

When we compile and run the test, it passes . However, there is a lot of duplication between the CatalogServiceStub and the DatabaseCatalogService . Let s refactor out the common parts into a base class called CatalogService :

 public abstract class CatalogService {    public RecordingDto FindByRecordingId(long id)    {       RecordingDataSet.Recording recording = FindById(id);       if(recording == null) return null;       return RecordingAssembler.WriteDto(recording);    }    protected abstract        RecordingDataSet.Recording FindById(long recordingId); } 

If you go back and look at the code for the CatalogServiceStub and the DatabaseCatalogService , the one thing that is different between them is the retrieval of the RecordingDataSet.Recording . The stub class creates the Recording in memory, and the database class retrieves it from the database. The CatalogService class uses an abstract method named FindById to allow derived classes to retrieve the Recording in the way that they see fit. Using the CatalogService base class, we can now modify the CatalogServiceStub to be the following:

 public class StubCatalogService : CatalogService    {       private RecordingDataSet.Recording recording;        public StubCatalogService(RecordingDataSet.Recording recording)       { this.recording = recording;}       protected override          RecordingDataSet.Recording FindById(long id)       {          if(id != recording.Id) return null;          return recording;       }    } 

We did rename the class to be StubCatalogService because we like the naming convention we used with the DatabaseCatalogService better. The following is the modified DatabaseCatalogService class:

 public class DatabaseCatalogService : CatalogService    {       protected override          RecordingDataSet.Recording FindById(long id)       {          RecordingDataSet dataSet = new RecordingDataSet();          return Catalog.FindByRecordingId(dataSet, id);       }    } 

We compile the code and rerun all our tests. They all pass, so we have successfully removed the duplication by introducing an abstract base class named CatalogService that now holds the common pieces of the code.

The rest of the tests in the DatabaseCatalogServiceFixture are similar to what we did for the stub. In fact, they are identical. This led us to believe that we could refactor them into one common base. It turns out that even though the tests are identical, the issues involved with different setup/ teardown behavior are so noticeable and the code is so complicated that it did not make sense to refactor out the commonality right now.