Note folks that the purpose of this is NOT to discuss the Pros and Cons of TDD, Unit Testing or whatsoever. The purpose is just to give a few examples. I would love if you help me when the complexity starts climbing.
If needed, for a quick understanding of what
TDD or
Unit Testing is, refer to the links above, or
check out the
book at the end of the article.
In TDD you don’t write the application code first, instead you write the test cases first. The TDD cycle is as follows:
- At the beginning you just write one test, and later on, more tests can be added.
- Make sure the initial test fails; this will validate the test harness.
- Write some code to pass the test. Important: don’t over-code. Just add the code needed to pass the test and period. The code does not have to be elegant at this point.
- Run the test: if it fails, then you have to go back to step 3 and fix your code in order to pass the test. When you succeed, then move on to step 5.
- Improve and optimize your code: make it elegant, more efficient, avoid duplications, etc, etc. This is called code refactoring.
- When refactoring your code, maybe, by accident, you break the functionality. How can you be sure that everything is working as it should? Just re-run your test and it will tell you if the previous refactoring introduced a failure or not.
- Go to step 1 and add a new test if needed.
The example: let’s consider the chess game. The goal will be to implement the code to verify whether a piece is placed in a valid position within the board. We are only going to implement one test: SetPositionTest.
I will number the columns (X coordinate) from 1 to 8 starting at the bottom left-hand corner. In the same way, I will number the rows (Y coordinate) from 1 to 8 starting at the bottom left-hand corner.
8
7
6
5
4
3
2
1 2 3 4 5 6 7 8
For a step by step tutorial of how to use, configure and setup
DUnit you can read the
English or
Chinese versions of the tutorial.
Initially, the testing code should look like this:
unit ChessPiecesTests;
interface
uses
TestFrameWork;
type
TPieceTest = class(TTestCase)
published
procedure SetPositionTest;
end;
implementation
uses
ChessPieces;
{ TPieceTest }
procedure TPieceTest.SetPositionTest;
begin
end;
initialization
TestFramework.RegisterTest(TPieceTest.Suite);end.
If you run that test, it will succeed since no checks are being performed within the SetPositionTest procedure.
Each test is composed by one or more checks. I suggest adding the checks little by little. Every time you add a check, you should add business code to pass the corresponding test.
Now, let’s make the test fail on purpose. For that, let’s add one check to the SetPositionTest procedure.
procedure TPieceTest.SetPositionTest;
begin
Check(True = False, '');
end;
True is never False. So, this test will fail. If it doesn’t fail, then something is wrong with you test harness. Fix it. You can remove this initial check once you run the test and it fails.
Now, let’s add a real check to our test. Something like this:
procedure TPieceTest.SetPositionTest;
var
Piece: TPiece;
begin
Piece:= TPiece.Create;
try
//Test trivial (normal) workflow
Check(Piece.SetPosition(4, 4) = True, '');
finally
Piece.Free;
end;
end;
If you run this test, you will get a compilation error! Yes, that’s right. You don’t have business code yet. You just have the test. This is what TDD is all about: test first, business code later. Get the point?
To avoid the compilation error, we will code a separate unit (ChessPieces) and we will add it to the uses clause of our ChessPiecesTests unit.
unit ChessPieces;
interface
type
TPiece = class
private
public
function SetPosition(aX, aY: Integer): Boolean;
end;
implementation
{ TPiece }
function TPiece.SetPosition(aX, aY: Integer): Boolean;
begin
end;
end.
Run the test again and now the compilation error is gone. Nonetheless, the test fails, because the Piece.SetPosition(4, 4) evaluates to False.
Let’s add the minimum business code possible to pass this test:
function TPiece.SetPosition(aX, aY: Integer): Boolean;
begin
Result:= True;
end;
This passes the test. What? Yes, this passes the test, right?
OK, what now? Well, we keep adding new checks to the test and every time this happens, we need to add new business code in order to pass it. It is very important to add checks to test the boundaries of whatever we are trying to code. I think you are getting the point, so I will just add a bunch of checks at once:
procedure TPieceTest.SetPositionTest;
var
Piece: TPiece;
begin
Piece:= TPiece.Create;
try
//Test trivial (normal) workflow
Check(Piece.SetPosition(4, 4) = True, '');
//Tests boundaries
Check(Piece.SetPosition(1, 1) = True, '');
Check(Piece.SetPosition(1, 8) = True, '');
Check(Piece.SetPosition(8, 1) = True, '');
Check(Piece.SetPosition(8, 8) = True, '');
//Test beyond the boundaries
Check(Piece.SetPosition(3, 15) = False, '');
Check(Piece.SetPosition(3, -15) = False, '');
Check(Piece.SetPosition(15, 3) = False, '');
Check(Piece.SetPosition(15, 15) = False, '');
Check(Piece.SetPosition(15, -15) = False, '');
Check(Piece.SetPosition(-15, 3) = False, '');
Check(Piece.SetPosition(-15, 15) = False, '');
Check(Piece.SetPosition(-15, -15) = False, '');
finally
Piece.Free;
end;
The test above is even checking for the attempts of positioning a piece outside the chess board.
To pass that test let’s write some business code:
function TPiece.SetPosition(aX, aY: Integer): Boolean;
begin
Result:= True;
if (aY < 1) or (aY > 8) then Result:= False
else if (aX < 1) or (aX > 8) then Result:= False;
end;
Run the test and see how it passes.
The code above could be refactored or even rewritten. The tests will remain the same, allowing us to catch any bugs introduced with the code change.
For instance, we could write the procedure above as follows:
function TPiece.SetPosition(aX, aY: Integer): Boolean;
begin
Result:= (aX > 0) and
(aX < 9) and (aY > 0) and
(aY < 9);
end;
Run the test, and it will tell you if this refactoring (or reimplementation) works ok.
It’s important to note that a good test should cover all possible scenarios and workflows. Pay special attention to the boundaries. At this point, a good understanding of the requisites is indispensable.
Finally, more and more tests will be needed in a real world application. Each test will have its own
checks. Each test will cover one piece of the functionality: this is what
unit testing is intended for.
I wrote a second article about
TDD, code refactoring and design patterns in Delphi (click here). I would appreciate any comments you could provide about it.
For further reading I recommend you
Test Driven Development: By Example by
Kent Beck. Check it out just below:
CodeProject
(years ago), I realized that there was a big obstacle (challenge) to implement it in Delphi: How to write a routine to really clone (not just recreate) an object? In other words, how to perform a 