I started with a dead simple app. Type your text into the edit box, click the button and the text shown in a label’s caption:

GUI for testing

So I started with a TGUITestCase descendant:

type
  MainFormTests = class(TGUITestCase)
  protected
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure Hookup;
  end;

DUnit runs the SetUp and TearDown methods before and after each test method. This is different than NUnit and other unit testing frameworks which call SetUp and TearDown once per test suite execution. So if in the SetUp we start the application and in the TearDown we close it then we will be starting and stopping the app for every test. This is undesirable in this type of testing since we will be changing state in application. Additionally it might slow the tests down to have to perform the application startup and shutdown over and over again.

To deal with this problem we’ll use a class from the TestExtensions unit called TTestSetup. TTestSetup is a decorator for a TTestCase. This means that you implement behavior before and after tests run … like setup and teardown code that should only run once. To get this done you need two things: 1) a subclass of TTestSetup in which you’ll do your one time setup and teardown and 2) do a little different test registration. Here’s the TTestSetup class:

uses TestFramework, TestExtensions, GUITesting, fMain;
 
type
  MainFormSetup = class(TTestSetup)
  private
    FMainForm : TForm1;
  protected
    procedure SetUp; override;
    procedure TearDown; override;
  end;

You can see here the main form reference for our test app and the SetUp and TearDown that will happen once. Next let’s see the TGUITestCase and the implementation code:

  MainFormTests = class(TGUITestCase)
  protected
    procedure TearDown; override;
  published
    procedure Hookup;
    procedure TestChangeEditText;
    procedure TestButtonClickWithText;
    procedure TestButtonClickWithNoText;
    procedure TestButtonClickWithOnlyWhiteSpace;
  end;
 
implementation
 
{ MainFormSetUp }
 
procedure MainFormSetUp.SetUp;
begin
  FMainForm := TForm1.Create(Application);
  FMainForm.Show;
  inherited;
end;
 
procedure MainFormSetUp.TearDown; 
begin 
  FMainForm.Release;
  FMainForm.Free;
  inherited
end;
 
{ MainFormTests }
 
procedure MainFormTests.Hookup;
begin
  Check(True);
end;
 
procedure MainFormTests.TearDown;
begin
  GUI := nil;
  inherited;
end;
 
procedure MainFormTests.TestButtonClickWithNoText;
var
  lbl: TLabel;
  LabelText: string;
begin
  RunGUITestSequence(LabelText, lbl, '');
  CheckEquals(LabelText, lbl.Caption);
end;
 
procedure MainFormTests.TestButtonClickWithOnlyWhiteSpace;
var
  lbl : TLabel;
  LabelText : string;
begin
  RunGUITestSequence(LabelText, lbl, '    ');
  CheckEquals(LabelText, lbl.Caption);
end;
 
procedure MainFormTests.RunGUITestSequence(var LabelText: string; var lbl: TLabel; const TestValue : string);
var
  Edit: TEdit;
begin
  lbl := FindControl('Label1') as TLabel;
  LabelText := lbl.Caption;
  Edit := FindControl('Edit1') as TEdit;
  Edit.Text := TestValue;
  Click('Button1');
end;
 
procedure MainFormTests.TestChangeEditText;
var
  Edit: TEdit;
begin
  Edit := FindControl('Edit1') as TEdit;
  Edit.Text := 'I like pizza';
  CheckEquals('I like pizza', Edit.Text);
end;
 
procedure MainFormTests.TestButtonClickWithText;
var
  lbl: TLabel;
begin
  Click('Button1');
  lbl := FindControl('Label1') as TLabel;
  CheckEquals('I like pizza', lbl.Caption);
end;
 
initialization
  RegisterTest(MainFormSetUp.Create(MainFormTests.Suite));

With the test registration above, the DUnit test tree looks a little different:

DUnit test tree with setup decorator

Now for the fun part.

You take these tests and recreate my test application. Comment below about how it went and what questions, if any, you had.

Scrum and XP both have an iteration planning method in which the team gives each unit of work (story) an estimation of effort. We typically call these story points. Story points are essentially an order of complexity against a baseline story.

The typical format is the Product Owner brings stories to the Team for estimation. The Product Owner and Team talk about each story until the Team feels comfortable giving an estimate. In the beginning of the iteration the Team decides how many story points they can get done and the Product Owner lines up the stories in priority order/ The team then pulls into the iteration as many stories as will fit based on the sum of the story points.

Teams will carry on like this using the sum of the story points they complete in each iteration as a measure of their productivity. Increasing this measure of productivity, called Velocity, is supposed to be a sign of a team getting better and delivering more business value each iteration. This is where I think we mess up: equating velocity with business value.

Why is equating Velocity with Business Value bad? I think we can draw the same distinction here as we draw between Activity and Action. Velocity is a measure of effort or cost. I say it will cost 5 times as many story points to complete story B as it does story A. So story B is more complex and will take more time to complete than story A. We presume that the stories on which we’re working are of the highest business value as compared to the stories remaining. As such we presume that if our Velocity goes up then we’re providing more Business Value.

This may be the case, but what if we could do even better? What if we could say that story A has a certain amount of Business Value points and story B also has a certain amount. By this I mean a number: 4 Business Value points or 10 Business Value Points. Lets look at that.

Here we have four stories ordered by Business Value points. This might seem like a reasonable ordering. In fact it seem like there’s no point in the Business Value column if all you’re doing is prioritizing by it.

For some time the world has had a method for calculating ones return on investment. We divide the value by the cost to get the return on investment. It’s a simple calculation used to bring order out of chaos. Let’s apply it to the above table and order by the resulting ROI numbers.

Now we get a slightly different ordering. Why would you care about this? Using the ROI calculation you minimize your effort and maximize your value delivery.

You might be looking at this thinking “Well, it’s all got to get done anyway so the order isn’t really important”. To that I would say you’ve taken your first step on the death march and I don’t envy that sort of thinking. Now in this time of economic trouble more than ever we need to concentrate on delivering more business value faster and with less effort than ever before.

On that note I’ll wrap up with a link to a wonderful techbiz parable: Rocks into gold

If I understand the problem correctly what we want is a way to mitigate the risk of choosing the wrong technology or technique. This is to say if we do choose the wrong technology or technique (for whatever reason) how do we recover and change direction with a minimal amount of fuss and cost.

I think the biggest guiding princple we have for this is Deferred Implmentation. Deferred Implementation demands implementation agnosticism from the client code. We’ll use the User Repository code from the post Keep you code lazy and ignorant as an example. When we wrote the code that needed to look up a user by the user name the client code was ignorant of how the data got there. This was good because it meant we could focus on the business logic of logging in and leave the details of how retrieve user information for later. All we needed to supply was an API for the client code to use. Later, in the next post, we wrote the code to retrieve the user data using an ADO connection to a SQL database. The truth is we could have used any storage medium like an XML file or web service. Either way the client code didn’t change because of the implementation details in the User Repository. Doing this created a hedge in both the barrier sense and the risk mitigation sense.

TDD played a big role in getting to the deferred implementation of the User Repository. We were able to quickly put together a test bed for our ideas and keep it to be sure we didn’t inadvertently break anything. TDD also gave us a formula for the incremental improvement of the code.

TDD by itself didn’t get the job done. We needed to be conscious of separation of concerns, not mixing object creation with business logic and design patterns that help us solve these sorts of problems.

I hope this addressed the question Craig posed. If not, I hope this was at least informative.

I’ve found myself lately writing code to solve a problem, looking at the volume of code and being upset over how little of it there is. I think, “Wow, I really wanted to solve a big problem. This code works but I can’t use it because there’s not enough here to match up with the magnitude of the problem!”. It’s like buying expensive software that comes in just a CD case. We shell out big bucks and only get a CD in a jewel case? No, no, no; I want to feel like I got my moneys worth!

How often do we do that? We start with this big cup and try to fill it up. We write more code than necessary,more tables than needed, more infrastructure, more text in the blog post, more, more, more.

The problem isn’t the work or the stuff; it’s the cup. We start with a big cup and try to fill it. Start with a small cup. If it overflows then great! Get a bigger cup.

It’s okay to get stuff done with less. Less code, less effort, fewer hours. Scale it back. Pare it down. Do just the bare essentials and do them exceeding well.

Heres to a new year of smaller cups. Happy new year, all!

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.

Lets review the code from the last post:

function TLogin.GetConnectionString : string;
var
  reg : TRegIniFile;
begin
  reg := TRegIniFile.Create('Software\MyApp');
  Result := reg.ReadString('Database', 'ConnectionString', '');
  FreeAndNil(reg);
end;
 
function TLogin.Execute(const UserName, Password : string) : Boolean;
var
  UserQuery : TADOQuery;
  DBUserPassword : string;
begin
  UserQuery := TADOQuery.Create(nil);
  try
    UserQuery.ConnectionString := GetConnectionString;
    UserQuery.SQL.Text := 'SELECT Password FROM Users WHERE UserName = ' + 
                         QuotedStr(UserName);
    UserQuery.Open;
    DBUserPassword := UserQuery.FieldByName('Password').AsString;
    UserQuery.Free;
    Result := DBUserPassword = Password;
  except
    Result := False;
  end;
end;

Now lets review the problems:

• Hidden dependencies - TLogin does not publish the fact that it relies on a connection to the database and needs a connection string from the registry.
• Mixing concerns - Business logic and object creation occur in the same block of code. This means you can’t test business logic without creating the dependencies.

All of these problems can be summed up as: Too much ceremony and too little essence. What is this class trying to do? Does creating a connection to the database, querying a table and handling exceptions have much to do with the purpose of logging in to the system?

Before we start solving problems lets think about the elements involved with our task of logging in to the system. We have someone who wants to log in, we have a system for authenticating this person and we have system for providing the data against which this person will be authenticated. These are our domain objects: User, Login and User Repository.

NOTE: I don’t say Database because I don’t want my vocabulary to influence the implementation. I might use a database and I might not. For now I want to keep my options open.

We will begin by stripping away all the stuff in the login code that does not directly relate to the login business rules. That leaves us with:

function TLogin.Execute(const UserName, Password : string) : Boolean;
begin
  Result := Password = DBPassword;
end;

That’s it, really. All the other stuff has nothing to do with the business of logging in to the system. The old code looked for everything. So lets do the opposite. Lets demand everything we need:

function TLogin.Execute(User : TUser; const Password : string) : boolean;
begin
  Result := Password = User.Password;
end;

That’s considerably simpler. We even eliminated a test. We no longer have to test the TLogin object for a failure to connect to the database. We also eliminated two dependencies: the database and the registry.

What did we demand? We asked for something called TUser that includes a field called Password. The expectation is that this TUser construct should be the user in question and should include their saved password from the database.

This makes the tests very simple as well. All I need to do is supply a TUser (which I could easily create by hand) and a password against which to compare. So the question is: when this code is in production from where will the TUser come? Lets start with what TUser looks like right now:

type
  TUser = record
    Password : string;
  end;

All we need right now is the password field. Now lets look at the tests:

procedure TLoginTests.SetUp;
begin
  FUser.Password := 'flinstone';
  FLogin := TLogin.Create;
end;
 
procedure TLoginTests.TearDown;
begin
  FreeAndNil(FLogin);
end;
 
procedure TLoginTests.TestGoodLogin;
begin
  CheckEquals(True, FLogin.Execute(FUser, 'flinstone'));
end;
 
procedure TLoginTests.TestBadLogin;
begin
  CheckEquals(False, FLogin.Execute(FUser, 'rubble'));
end;

That’s considerably less code. It’s even pretty easy to read. So why is this better than the code from the previous post?

• There’s less of it
• It only performs the task at hand: logging in to the system
• It’s honest about what it does - there are no hidden dependencies
• You can now test the business logic in isolation

Now lets anwser the other burning question: In production, from where will we get the TUser that TLogin demands. Good question. Lets manifest some code:

procedure TUserRepositoryTests.SetUp;
begin
  FRepo := TUserRepository.Create;
end;
 
procedure TUserRepositoryTests.TearDown;
begin
  FreeAndNil(FRepo);
end;
 
procedure TUserRepositoryTests.TestValidUserLookup;
begin
  user := FRepo.Lookup('fred');
  CheckEquals('flinstone', user.Password);
end;

The fake-it-til-you-make-it principle tells us we should do the following:

function TUserRepository.Lookup(const UserName : string) : TUser;
begin
  Result.Password := 'flinstone';
end;

That’s enough code to make the test pass. Let’s add another test:

procedure TUserRepositoryTests.TestInvalidUserLookup;
begin
  user := FRepo.Lookup('barney');
  CheckEquals('', user.Password);
end;

Our test tells us two things about the user repository business logic:

1. The user repository returns a blank password when a user cannot be found
2. A blank password is never valid for a user

Running the test confirms that it fails because of our fake implementation. Now we get solve the real problem: how to make TUserRepository flexible so that we can test drive it. TUserRespository needs to get its data from somewhere both in the test suite and in production.

ILoadable = interface
  procedure AddRecord(const UserName, Password : string);
end;
 
ILoader = interface
  procedure Load(Target : ILoadable);
end;

NOTE: This seems to be referred to as the Data Provider or just Provider pattern.

An object implementing ILoader will be responsible for providing data to an object implementing ILoadable. An object implementing ILoadable will be responsible for asking ILoader to load it with data and storing that data. We’ll have TUserRepository implement ILoadable to ensure that it is data source agnostic. This will meet our goal of keeping TUserRepository test-drivable and production worthy. Let’s look at the implementation code:

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;
 
implementation
 
constructor TUserRepository.Create(Loader : ILoader);
begin 
  FUsers := TStringList.Create;
  Loader.Load(Self);
end;
 
destructor TUserRepository.Destroy;
begin
  FreeAndNil(FUsers);
end;
 
procedure TUserRepository.AddRecord(const UserName, Password : string);
begin
  FUsers.Add(Format('%s=%s', [UserName, Password]));
end;
 
function TUserRepository.Lookup(const UserName : string) : TUser;
begin
  Result.Password := FUsers.Values[UserName];
end;

I think you’ll agree that we’ve done the minimal amount of work here. Right now all we care about is looking up a user by their user name and providing the associated password. As such, a TStringList will do.

Now we’ve introduced a dependency. TUserRespository depends on an ILoader to provide its data. How is that any different than the code from the previous post? First, TUserRepository is honest about its dependency; you can’t create it without providing an ILoader. Second, rather than have TUserRepository demand a concrete object it asks for an interface. This is good because TUserRepository has to know nothing about the actual implementation of ILoader or even from where the data is being provided.

Since we’ve added this dependency we need to update our test:

implementation
 
type
  TTestData = class(TInterfacedObject, ILoader)
  protected
    procedure Load(Target : ILoadable);
  end;
 
procedure TTestData.Load(Target : ILoadable);
begin
  Target.AddRecord('fred', 'flinstone');
end;
 
procedure TUserRepositoryTests.SetUp;
begin
  TestData := TTestData.Create;
  FRepo := TUserRepository.Create(TestData);
end;
 
procedure TUserRepositoryTests.TearDown;
begin
  FRepo := nil;
end;

We needed to provide TUserRepository with an ILoader. Because we want to control the data we create a stub ILoader with TTestData that only loads the ILoadable with one record. In production we would need to create TUserRepository with an ILoader that provides data from the production data source. This is where we might connect to a database and query a table. I’ll leave how to create and test this portion of the code for another post.

Take aways

How did we solve our problems?

• Dependency injection. Rather than have our code look for or create what it needed we demanded everything upfront. We kept our code as ignorant as possible. This helped us separate the business logic from object creation and allowed us to test the business logic in isolation.




• Inversion of control. Each piece of code asked its dependencies to do all the work. Our code was not only ignorant, it was also as lazy as possible.




• Separation of concerns. Each piece of code only implemented the business logic relevant to its task. Each of the three domain objects did only what was needed and left the details to its dependencies. None of them meddled in the affairs of the others.

The wrap-up

In the next post I’ll cover how to use FitNesse to test the code that will provide live data to the TUserRepository.

I hope you enjoyed the article.

Additional information

Check out this Google talk: Clean Code Talks - Dependency Injection
Get the slides here: Link

Check this article: Ending Legacy Code in our lifetime

On with the show …

You will not learn what you need to know from a TDD course/book/lecture. When you walk away you will not be able to write better software. You will not be able to test drive all your code in a fully automated test suite. Your expectations will not be met and you will quickly dump the whole concept of Test Driven Development.

It’s true.

The problem has nothing to do with TDD. The problem is that you don’t know how to write better software. TDD will not make you a coding rock star. You will not be the envy of your peers. Your face will not be printed on a t-shirt (I don’t think that’s ever happened but it would be cool).

So what’s the hype with TDD, BDD, ATDD, LMNOP, QRS, ETC? The truth is to be successful with TDD you must either 1) already be good at writing great software or 2) get good at writing great software. If you’re already good at writing great software and/or already being successful with TDD then you’re probably reading this for entertainment. As such I’ll forgo any further exposition on that point.

So how do you get good and writing great software? Examine the aspects of code that make software difficult or impossible to test. Software that is testable has a far greater chance at being great software than code that is not testable.

What are the aspects of code that software difficult to test? While there are many the primary culprit is Dependancies. How is the expressed as a symptom of non-testablity in code? It comes primarily from the mixing of object creation and business logic.

Let’s see an example of this:

You’re fresh out of TDD school (or whatever) and you sit back down at your desk at work to tackle your first code task. It’s a simple task - log in to the system. You think “No problem!” and create your first test case:

procedure TLoginTests.TestGoodLogin;
var
  login : TLogin;
begin
  login := TLogin.Create;
  CheckEquals(True, login.Execute('fred', 'flinstone'), 'Login should have succeeded!');
  FreeAndNil(login);
end;

Looks easy enough, right? You run the test, it fails and all seems right with the world! Now you add some code to make the test pass:

type
  TLogin = class(TObject)
  public
    function Execute(const UserName, Password : string) : Boolean;
  end;
 
implementation
 
function TLogin.Execute(const UserName, Password : string) : Boolean;
begin
  Result := True;
end;

You run the test and see it pass! You’re happy that you followed the method, did the simplest thing possible to make the test pass and now you’re ready for the next step: Refactor. You examine the code and decide you don’t really need to do any refactoring right now. Go Team!!

Now you write the next test:

procedure TLoginTests.TestBadLogin;
begin
  login := TLogin.Create;
  CheckEquals(False, login.Execute('fred', 'rubble'), 'Login should have failed!');
end;

You run the test and see it fail. Huzzah! Now it’s time to add the code to make the test work. You think for a second about simply making the function return false but you know better than that. So what is the simplest thing? You need to query the database, retrieve the record for this user and validate the password, right?

function TLogin.Execute(const UserName, Password : string) : Boolean;
var
  UserQuery : TADOQuery;
  DBUserPassword : string;
begin
  UserQuery := TADOQuery.Create(nil);
  UserQuery.ConnectionString := 'Driver={SQL Native Client};' +
                                'Server=localhost;' +
                                'Database=SecurityDatabase;' +
                                'Uid=myUsername;' +
                                'Pwd=myPassword;';
  UserQuery.SQL.Text := 'SELECT Password FROM Users WHERE UserName = ' + 
                         QuotedStr(UserName);
  UserQuery.Open;
  DBUserPassword := UserQuery.FieldByName('Password').AsString;
  UserQuery.Free;
  Result := DBUserPassword = Password;
end;

(You’re welcome to beat the SQL injection horse to death in the comments)

Whew! You run the tests and find both tests fail. Ouch. Feeling silly, you add the user “fred” into the database with a password of “flinstone” and run the tests again. Success! The tests pass. Now it’s time for refactoring.

The most obvious problem is that your production code can’t be hard coded to talk to your local database with a bad set of login credentials. Looks like the hard coded connection string had got to go:

  ...
  UserQuery.ConnectionString := GetConnectionString;
  ...
 
function TLogin.GetConnectionString : string;
var
  reg : TRegIniFile;
begin
  reg := TRegIniFile.Create('Software\MyApp');
  Result := reg.ReadString('Database', 'ConnectionString', '');
  FreeAndNil(reg);
end;

This time you were a smarty pants and added the registry entry before running the tests! You find the tests still pass. Sweet! TDD rocks!

Any more refactoring needed? Nothing stands out. Any more tests to write? We’ve a test for a good login and a bad login … that seems sufficient. Let’s check it in and get the tests added to the build system.

You arrive the next morning ready to tackle your next challenge but find an email from the build system politely informing you that you broke the build. Damn. The tests passed on my machine. Stupid build system. So what’s the problem? The test failed with an exception - cannot connect to the database. Damn, guess we needed another test after all. You know that your code reads the connection string from the registry and you know that the connection in your registry is correct. That means you need to save your good connection string, write a bad (or blank) connection string, execute the code and put the good connection string back:

procedure TLoginTests.TestDatabaseConnectionFailure;
begin
  reg := TRegIniFile.Create('Software\MyApp');
  OldConnectionString := reg.ReadString('Database', 'ConnectionString', '');
  reg.WriteString('Database', 'ConnectionString', 'NO CONNECTION FOR YOU!!');
  login := TLogin.Create;
  CheckEquals(False, login.Execute('This', 'Does Not Matter'));
  reg.WriteString('Database', 'ConnectionString', OldConnectionString);
  FreeAndNil(login);
  FreeAndNil(reg);
end;

Hmm, that was alot trouble to go to simulate no connection to the database. You run the tests and they blow up. Cool. Now you can fix the problem:

function TLogin.Execute(const UserName, Password : string) : Boolean;
var
  UserQuery : TADOQuery;
  DBUserPassword : string;
begin
  UserQuery := TADOQuery.Create(nil);
  try
    UserQuery.ConnectionString := GetConnectionString;
    UserQuery.SQL.Text := 'SELECT Password FROM Users WHERE UserName = ' + 
                         QuotedStr(UserName);
    UserQuery.Open;
    DBUserPassword := UserQuery.FieldByName('Password').AsString;
    UserQuery.Free;
    Result := DBUserPassword = Password;
  except
    Result := False;
  end;
end;

That ought to do it. Running the tests confirms it - the code now gracefully handles no connection to the database. The tests pass so let’s check it in. Hmmm, what a bunch of work that was. Seems like the test code was a little complicated.

Another build cycle completes and you get another broken build email. Yikes, that’s two! The test for the bad login passed while the test for the good login failed. You know that you’re handling the no-connection scenario so it can’t be that. The test database must be missing the user with which you’re driving your test. Inspecting the database proves your theory. You add the user “fred” with password “flinstone”. So now, provided you can connect to the database you should be golden … hmmm, connect to the database. Better check that the build machine has the connection string in the registry. You don’t want a third broken build email. Sure enough, no connection string in the registry. You quietly add it and pray that nothing else goes wrong.

You sure have to jump though a lot of hoops to make this TDD stuff work. To have gotten this all right the first time you needed to have:

1. Checked in the code
2. Added the user into the test database
3. Added the connection string to the registry on the build machine

You come in the next day to another broken build email. What the ?!?!?!!! Again, the test for the bad login passed while the test for the good login failed. How can that possibly be? After some investigation you find that another test is clearing the Users table and leaves it empty before your test runs. Wow. So in your test you have to guarantee that the user you need in your test exists:

procedure TLoginTests.TestGoodLogin;
var
  login : TLogin;
  reg : TRegIniFile;
  UserQuery : TADOQuery;
begin
  UserQuery := TADOQuery.Create(nil);
  reg := TRegIniFile.Create('Software\MyApp');
  UserQuery.ConnectionString := reg.ReadString('Database', 'ConnectionString', '');
  reg.Free;
  UserQuery.SQL.Text := 'INSERT INTO Users VALUES(' +
    QuotedStr('fred') + ',' + QuotedStr('flinstone') + ')';
  UserQuery.ExecSQL;
  UserQuery.Free;
  login := TLogin.Create;
  CheckEquals(True, login.Execute('fred', 'flinstone'), 'Login should have succeeded!');
  FreeAndNil(login);
end;

You run your test and it blows up - the query is complaining that the user “fred” already exists. Grrr:

  ...
  try
    UserQuery.ExecSQL;
  except
    // shhhh.
  end;
  ...

Now your test passes. Just to be sure, you delete the user “fred” from your database and test again: success. Good grief!

You sure had to do a lot of work to make that simple set of tests passing. Let me give you a glimpse into the future of what those tests will look like:

procedure TLoginTests.TestGoodLogin;
{
var
  login : TLogin;
  reg : TRegIniFile;
  UserQuery : TADOQuery;
}
begin
  Check(True);
{
  UserQuery := TADOQuery.Create(nil);
  reg := TRegIniFile.Create('Software\MyApp');
  UserQuery.ConnectionString := reg.ReadString('Database', 'ConnectionString', '');
  reg.Free;
  UserQuery.SQL.Text := 'INSERT INTO Users VALUES(' +
    QuotedStr('fred') + ',' + QuotedStr('flinstone') + ')';
  try
    UserQuery.ExecSQL;
  except
    // shhhh.
  end;
  UserQuery.Free;
  login := TLogin.Create;
  CheckEquals(True, login.Execute('fred', 'flinstone'), 'Login should have succeeded!');
  FreeAndNil(login);
}
end;
 
procedure TLoginTests.TestBadLogin;
begin
  Check(True);
{
  login := TLogin.Create;
  CheckEquals(False, login.Execute('fred', 'rubble'), 'Login should have failed!');
}
end;

The punch-line

So how did this turn into such a nightmare? Shouldn’t this have been an easy proposition? Is TDD to blame for the trouble and the extended completion time-line?

Lets look at the problems:

The dependencies: the data in the database and the connection string in the registry. That little bit of code that read a user from the database and a connection string from the registry created a testing nightmare.

The mixing of concerns: the login code had to be concerned with business logic as well as where to find the needed pieces of data.

How do we solve these problems? In the next article we’ll look at some techniques to help refactor this code into something that’s test-drivable, flexible and robust. I also hope that you’ll find something to help you avoid this type of nightmare in the future.

Notes

I know the first test would not compile until adding the implementation code.
I know this login code is susceptible to SQL injection.
I know this login code is not even remotely secure.
I know that you should compare hashed passwords; not plain text passwords.
I know that the example gets a little long-winded. Thanks for making it this far.
There are a number of recent blog posts that have inspired this article. I’ll list them in the next part.

I’ve always considered programming/engineering/development to be more art than science. I guess you can chalk it up to my background in the arts. What hit home for me was the assertion that any kind of work done without an underlying philosophy is wicked boring and unfulfilling.

The article notes that other arts have established and accepted schools of thought and philosophy. For instance, painting has Cubism, Impressionism, etc. Do we have schools of thought and philosophy? Do we have Waterfall, Agile, Do-Whatever-It-Takes-To-Ship, TDD, BDD?

What about you? Do you employ any sort of philosophy in your work?

All the major fixtures have been ported (Column Fixture, Row Fixture, Action Fixture, Table Fixture, Row Entry Fixture).

What does this mean to you? Check out The Need for Automated Acceptance Testing. FitNesse is a tool created to fit this need (no pun intended).

What’s great about automated acceptance testing? In short: concrete examples straight from the customer. FitNesse is also a way to get executable specifications. FitNesse does its work in the form of a wiki. You can organize tests into hierarchal test suites that are editable the way any wiki is. This provides a familiar and friendly interface for non-technical types. All of this adds up to an environment in which tests can be written and organized in such a way that they specify desired functionality before the code is written and serve as documentation after the fact. No more having to interpret written specs into tests and production code.

It takes some training both on the developer’s part and the customer’s part but it’s well worth the effort.

1. Take a class, any class and instantiate it in a test harness.
2. Find a coworker, let them read your code and tell you what it does.
3. Count the instances of duplication in your code.

Why take this test?

Number 1.
The ability to instantiate any class in a test harness demonstrates the level of decoupling and cohesion of your code. Why is that good? Highly decoupled cohesive code promotes: seperation of concerns, low duplication and extensiblity. You end up with only as much code as you need. You also get the power to duplicate and isolate customer found defects before fixing them, giving you a collection of tests you can rely on to prove the integrity of your code and design.

Number 2.
To often we write code that is write-once/read-never. Your code should be expressive of it’s intent and easy to read. It should do what it says and say what it does. Code spends more time being read and maintained than being originated. Additionally, when you’re writing highly decoupled code the more readable your code the more likely someone can come behind you and maintain/extend your work.

Number 3.
Duplication is the bane of maintainability. You (and I) have copy-and-pasted code from one unit to another to tweak it for some slightly different functionality. Stop it. Refactor that code into a superclass or into seperate object and use a subclass for specific functionality (see the Strategy Pattern). Duplication has more than one face: copy-and-paste (as I just talked about), and reinventing the wheel. On a larger team it easy to reinvent functionality that another team member wrote prior to you. Don’t be afraid to query your peers when you get that “someone must have done this before” feeling. You’ll reduce the complexity and size of your project by eliminating functional duplication.

How do you get there?

Check out:

• Eric Evans’s Domain Driven Design (don’t be put off by this rather large volume, it’s worth the read).
• Dan North’s thoughts on Behavior Driven Development - especially the precept of working from the outside in (which lines up with the “eat your own dog food” principle).
• Martin Fowler’s Refactoring (great book)
• Design Patterns - I really liked Head First Design Patterns by Eric Freeman, et al.
• Refactoring to Patterns by Joshua Kerievsky

So how did it go? Post your test experience in the comments.

Full Disclosure
I stood on the shoulders of the following giants to write this post:
Dave Astels
Michael Feathers