Unit testing in Delphi - how are you doing it? [closed]

Question

I'm wondering how the few Delphi Programming users here are doing unit testing, if any? Is there anything that integrates with the Delphi IDE that you've found works well? If not, what tools are you using and do you have or know of example mini-projects that demonstrate how it all works?

Update:

I forgot to mention that I'm using Borland Developer Studio 2006 Pro, though I occasionally drop into Delphi 7, and of course others may be using other versions.

Linkman

Answer 1

DUnit is a xUnit type of unit testing framework to be used with win32 Delphi. Since Delphi 2005 DUnit is integrated to a certan point into the IDE. Other DUnit integration tools for the Delphi IDE can be found here. DUnit comes with documentation with examples.

Maddy

Answer 2

There are some add-ons for DUnit, maybe this is worth a new entry on SO. Two which I can put on the list now are

1. FastMM4 integration: Unit tests will automatically detect memory leaks (and other things), works with DUnit 9.3 and newer
2. OpenCTF is a 'component test framework' based on DUnit, it creates the tests dynamically for all components in the project's forms, frames and datamodules, and tests them using customized rules (open source)

Hardwick

Answer 3

DUnit2 is available from http://members.optusnet.com.au/~mcnabp/

DUnit2 is modified more regularly than the original dunit. It also works on Delphi 2009.

Try: http://sourceforge.net/projects/dunit2/ - it moved as the original author Peter McNab passed away several years ago. Still some activity on the dunit mailing list.

Brigandage

Repository in github cannot be found anymore. – Testimonial

Answer 4

There's a new unit testing framework for modern Delphi versions in development: https://github.com/VSoftTechnologies/DUnitX

Clinandrium

Answer 5

You could take a look at the unit testing classes available in our SynCommons open source unit. It's used in our Open-Source framework for all regression tests. It's perhaps not the best, but it's worth taking a look at it.

See http://blog.synopse.info/post/2010/07/23/Unit-Testing-light-in-Delphi

In order to implement an unit test, you just declare a new test case by creating a class like this:

type
  TTestNumbersAdding = class(TSynTestCase)
  published
    procedure TestIntegerAdd;
    procedure TestDoubleAdd;
  end;

procedure TTestNumbersAdding.TestDoubleAdd;
var A,B: double;
    i: integer;
begin
  for i := 1 to 1000 do
  begin
    A := Random;
    B := Random;
    CheckSame(A+B,Adding(A,B));
  end;
end;

Then you create a test suit, and run it.

In the up-to-come 1.13 version, there is also a new logging mechanism with stack trace of any raised exception and such, just like MadExcept, using .map file content as source.

It's now used by the unit testing classes, so that any failure will create an entry in the log with the source line, and stack trace:

C:\Dev\lib\SQLite3\exe\TestSQL3.exe 0.0.0.0 (2011-04-13)
Host=Laptop User=MyName CPU=2*0-15-1027 OS=2.3=5.1.2600 Wow64=0 Freq=3579545
TSynLogTest 1.13 2011-04-13 05:40:25

20110413 05402559 fail  TTestLowLevelCommon(00B31D70) Low level common: TDynArray "" stack trace 0002FE0B SynCommons.TDynArray.Init (15148) 00036736 SynCommons.Test64K (18206) 0003682F SynCommons.TTestLowLevelCommon._TDynArray (18214) 000E9C94 TestSQL3 (163) 

The difference between a test suit without logging and a test suit with logging is only this:

procedure TSynTestsLogged.Failed(const msg: string; aTest: TSynTestCase);
begin
  inherited;
  with TestCase[fCurrentMethod] do
    fLogFile.Log(sllFail,'%: % "%"',
      [Ident,TestName[fCurrentMethodIndex],msg],aTest);
end;

The logging mechanism can do much than just log the testing: you can log recursive calls of methods, select the information you want to appear in the logs, profile the application from the customer side, writing published properties, TList or TCollection content as JSON into the log content, and so on...

The first time the .map file is read, a .mab file is created, and will contain all symbol information needed. You can send the .mab file with the .exe to your client, or even embed its content to the .exe. This .mab file is optimized: a .map of 927,984 bytes compresses into a 71,943 .mab file.

So this unit could be recognized as the natural child of DUnit and MadExcept wedding, in pure OpenSource. :)

Additional information is available on our forum. Feel free to ask. Feedback and feature requests are welcome! Works from Delphi 6 up to XE.

Merna

Answer 6

Usually I create a Unit test project (File->New->Other->Unit Test->Test Project). It contains the stuff I need so it's been good enough so far.

I use delphi 2007 so I don't really know if this is available in 2006.

Spleen

Answer 7

We do unit testing of all logic code using DUnit and use the code coverage profiler included in AQTime to check that all paths through the code are executed by the tests.

Racer

Answer 8

We have two approaches, first we have Dunit tests that are run buy the developers - these make sure that the code that has just been changed still works as before. The other approach is to use CruiseControl.NET to build executables and then run the dunit tests everytime a change is made, to ensure that there are no unintended consequences of the change.

Much of our codebase has no tests, so the automatic tests are a case of continuous development in order to ensure our applications work as we think they should.

Mannos

Answer 9

We tried to use DUnit with Delphi 5, but it didn't work well. Specially if you are implementing COM interfaces, we found many dependencies to setup all the test infrastructure. I don't know if the test support has improved in newer versions.

Margarine