delphiXtreme

This is the third article in a series beginning with Busting the great TDD myth and Keep your code ignorant and lazy. If you haven’t already read these articles I recommend checking them out as I will continue to use the same code as an example.

In the last article we looked at using the Provider pattern to make a flexible data access layer. It allowed us to test our TUserRepository in isolation even though it is dependent on data. Lets breifly review that code:

type
  ILoadable = interface
    procedure AddRecord(const UserName, Password : string);
  end;
 
  ILoader = interface
    procedure Load(Target : ILoadable); 
  end;
 
  TUserRepository = class(TInterfacedObject, ILoadable)
  private
    FUsers : TStringList;
  protected
    procedure AddRecord(const UserName, Password : string);
  public
    constructor Create(Loader : ILoader);
    destructor Destroy; override;
    function Lookup(const UserName : string) : TUser;
  end;
 
  TTestData = class(TInterfacedObject, ILoader)
  protected
    procedure Load(Target : ILoadable);
  end;

By having TUserRepository implement ILoadable and creating a stub for loading test data called TTestData we were able to write a test like this:

procedure TUserRepositoryTests.SetUp;
begin
  TestData := TTestData.Create;
  FRepo := TUserRepository.Create(TestData);
end;
 
procedure TUserRepositoryTests.TestValidLookup;
var
  user : TUser;
begin
  user := FRepo.Lookup('fred');
  CheckEquals('flinstone', user.password);
end;

What’s good about this arrangement is that we’ve tested the business logic of TUserRepository independent of a data source. However we’re left the question of how to write and test the actual production code that will provide live data to TUserRepository. We could test-drive this code in a unit test but the rules of TDD tell us that a test should not need external dependencies. Also, accessing a database in a unit test would slow down the test suite. So how do we test this code?

FitNesse

FitNesse is a framework for automated acceptance testing. It has two faces: the outward (or customer facing) wiki and the internal (or developer facing) framework. We’ll tackle the task of creating and test-driving the live data provider for TUserRepository using FitNesse.

Before taking on this task, the first thing you’ll need is a copy of FitNesse. You can download the latest version at the website fitnesse.org.

The first step will be to write the test. This takes shape as a page on your FitNesse wiki:

|UserRepoDataFixture|
|UserName|Password|
|fred|flinstone|

This will be rendered on the wiki page like this:

User repo data fixture table

NOTE: I won’t cover how to create wiki pages in FitNesse. For this article I created a suite called SuiteExample and added a test page called TestUserRepoDataSource.

Clicking the Test link on the left side of the page will result in an error telling you that UserRepoDataFixture could not be found. So, you guessed it, the next step is to write the UserRepoDataFixture.

You need to grab the Delphi implementation of the FitNesse framework from the website http://code.google.com/p/fit4delphi/.

The test above is based on the Row Fixture. This sort of fixture is good for testing data sets. We’ll inherit our UserRepoDataFixture from TRowFixture.

type
  UserRepoDataFixture = class(TRowFixture)
  public
    function query : TList; override;
    function getTargetClass : TClass; override;
  end;

The Row Fixture requires that you do two things: (1) provide a list of objects that will represent the data set and (2) provide the class type of that object.

function UserRepoDataFixture.query : TList;
var
  user : TUser;
begin
  user.UserName := 'fred';
  user.Password := 'flinstone';
  Result := TList.Create;
  Result.Add(user);
end;
 
function UserRepoDataFixture.getTargetClass : TClass;
begin
  Result := TUser;
end;

You’ll see that we finally needed to add the UserName field to TUser. I know that some of you have been secretly screaming that TUser should have had this field from the start. Feel better?

We can build the fixture code and run the test and see that it passes. This is good because it tells us that our fixture code is being found and executed by the Delphi fit server. We still need to do the actual work:

function UserRepoDataFixture.query : TList;
var
  user : TUser;
begin
  Result := TList.Create;
  UserDS := TUserRepoDataSource.Create;
  Repo := TUserRepository.Create(UserDS);
  for user in Repo do
    Result.Add(user);
end;

What’s cool about this is that we didn’t have to instantiate our TUserRepository any differently than we did in our unit test. All we needed was to hand it a different implementation of ILoader.

Now some code for the TUserRepoDataSource:

type
  TUserRepoDataSource = class(TInterfacedObject, ILoader)
  private
    function Connect : Boolean;
    function MoreData : Boolean;
    function Current : TUser;
    procedure MoveNext;
  protected
    procedure Load(Target : ILoadable);
  end;
 
implementation
 
procedure TUserRepoDataSource.Load(Target : ILoadable);
begin
  if Connect then begin
    while MoreData do begin
      Taget.AddRecord(Current.UserName, Current.Password);
      MoveNext;
    end;
  end;
end;
 
{ SNIP }

I’ve omitted the rest of the implementation for the sake of brevity. You can tell from the Load method that this class would connect to a data source (such as a database) and loop over the result set to add each record to the ILoadable. I’ve also implied that we should add an enumerator to TUserRepository. This is one solution to the problem of how to pull the data out for the user repository. You might choose another based on your needs or your particular version of Delphi. The crux of the code is the same: load data into TUserRepository and read it back out.

Now we face the same problem as in the first article: our test relies on data. We can run this test and it might pass on our development box but fail on the build machine because our expected data is not present. One of the ways we can solve this problem is using the SetUp and TearDown facilities of FitNesse. We’ll add these pages to our SuiteExampe wiki page:

^SetUp
^TearDown

In the SetUp page we’ll add:

!|ExecSqlFixture|
|INSERT INTO User (UserName, Password) VALUES(’fred’, ‘flinstone’)|

In the TearDown page we’ll add:

!|ExecSqlFixture|
|DELETE FROM User WHERE UserName = ‘fred’|

Once that’s done out test page will render like this:

Test page with SetUp and TearDown

NOTE: At the time of this writing there are no database FitNesse fixtures written for Delphi. In this example I’ve used a fictional fixture called ExecSqlFixture. While it does not currently exist, writting this fixture shouldn’t be too much trouble.

Now our test assures our test data will be present before the test fixture is run and cleans up after itself at the end. This example presumes to use a SQL database as its data store. You might choose a different implementation and write different setup and tear down code.

Running the test now should find everything in order. Take some time and fiddle around with the test. Row Fixture does some neat things when you specify data that is not present and when you don’t specify data that is present.

Why is this better than what we did in the first article?

TDD prescribes that the tests should execute very fast. If they’re slow to execute then you won’t run then as often. So we move tests that are dependent on external dependencies out into the acceptance testing realm. We like this because it forces us to use a method that makes our code data source agnostic which in turn means we can test business logic in isolation. Using patterns like Factory or Builder we can take another step and write a number of different data access components and switch them in or out as we see fit.

FitNesse has considerably more benefits than what I’ve shown here. Because FitNesse is a wiki it’s easily accessible by non-tech types such as product owners and customers. In a perfect world the product owner and customer would have a suite of acceptance tests written before you started coding. These would act as executable product specifications … no more lengthy specs that get out of date and irrelevant!

I hope you enjoyed this three part series.

XP acceptance testing, fitnesse