How can I test functions and procedures as they don't belong to classes in Delphi?

Question

I have several little functions in an old Unit called Utils.pas.

Now I'd like refactoring some of them, but I think it's better to write test before. With DUnit I think it's impossible without a class.

So I'd like to know how can I test them before refactoring?

Edit:

I thought it was impossible because I was trying to add a test case in Delphi using Test Case Wizard. See the picture bellow that there aren't any classes and methods, so I'm not be able to create it.

Answer 1

You can't test a standalone function using the wizard but it's not a problem to test a standalone function with DUnit.

Example

  //***** A Standalone function te be tested in a unit far, far away
  function Add(v1, v2: Integer): Integer;
  ...

  //***** A testclass to contain the testmethods calling our 
  //      standalone function     
  TTestAdd = class(TTestcase)
  published
    procedure AddingComplement_ShouldEqualZero;
    procedure AddingNegativeNumbers_ShouldBeLessThanZero
    ...
  end;

  implementation

  procedure TTestAdd.AddingComplement_ShouldEqualZero;
  begin
    // Setup, Execute & Verify
    CheckEquals(0, Utils.Add(-1, 1), 'Complement doesn''t add to zero');
  end;

  procedure TTestAdd.AddingNegativeNumbers_ShouldBeLessThanZero
  begin
    // Setup, Execute & Verify
    CheckEquals(-3, Utils.Add(-1, -2), 'Add doesn''t add');
  end;

Answer 2

AFAICT, DUnit does not require code under test to exist as class methods. Only the test cases themselves must be classes.

EDIT: The wizard is just a convenience. You don't have to use it.

Answer 3

Real code needs to be maintained. Real code has assumptions that are not well documented. Real code is changed by people who forget or never knew those assumptions. Trust the tests, dont trust the code.

Real TDD allows you to create the object and its methods before implementation. You need a clear model before you can write a test case anyway.

So generate the object(s), add the methods, parameters etc. Probably using UML2 would be best, then write the test cases for those, and then implement the objects. After that run the profiler and find out how horrible your code really is, and refactor.

As a general solution it is almost always best to write a factory object to instantiate and initialize your objects. The closer you get to core functionality the more this becomes important.

Write tests for your expected failures and exceptions. use a check to make sure.

Finally write each test and watch it fail before you write the code to make it succeed.