Serg recent wrote an introduction to unit testing under Lazarus, showing how everything is there, but just that little bit “off” because of different unit names between FPCUnit and DUnit.
Not being a fan of ifdef, the prospect of having unit tests “uses” sections littered with ifdef did not attract me, so I made a little adapter unit to keep the “uses” sections clean.
It simply aliases the useful unit tests classes and units and goes like:
unit dwsXPlatformTests;
interface
uses
Classes, SysUtils,
{$ifdef FPC}
fpcunit, testutils, testregistry
{$else}
TestFrameWork
{$endif}
;
type
{$ifdef FPC}
TTestCase = fpcunit.TTestCase;
{$else}
TTestCase = TestFrameWork.TTestCase;
{$endif}
procedure RegisterTest(const testName : String; aTest : TTestCaseClass);
implementation
// RegisterTest
//
procedure RegisterTest(const testName : String; aTest : TTestCaseClass);
begin
{$ifdef FPC}
testregistry.RegisterTest(aTest);
{$else}
TestFrameWork.RegisterTest(testName, aTest.Suite);
{$endif}
end;
With it, unit test cases can just refer “dwsXPlatformTests”, which encapsulates the ugly ifdef’ing.
Surely there are loads more differences than that?
As far as the unit test framework goes (at least what’s used in the DWScript unit tests), those where the only adaptation required to make them “cross-compile”.
I’ll probably uncover more as I get all the libraries to the point where unit tests pass (not just compile), and keep the unit updated in the Googlecode SVN, but there seems to be a very high level of compatibility.
Most of the changes I’m dealing with are actually in the library code:
– String is UnicodeString in Delphi, AnsiString in FPC
– slight differences in generics
– no closures/anonymous methods in FPC
The last two were rather straightforward to solve, UnicodeString/AnsiString is proving more complicated.
I would created a unit TestFrameWork.pas for FPC, and add the alias and maybe inherit the class and overload the methods to match the delphi version. So, you can keep using only TestFrameWork.pas for both projets.
Since DUnit already exists for more than a decade and is open source I really wonder why that had to be reinvented for FPC instead of just adding a few ifdefs to the DUnit source (like I did years ago with Zeos).
@Cesar Romero
But then you need to ‘hide’ that unit from Delphi by playing with config options, and config options are either machine specific (need to be replicated manually on all machines) or project specific (need to replicate them in all test projects).
The adapter unit works with no special requirement and can be part of the regular project folder.
@Stefan Glienke
License issues could be one reason: DUnit is under MPL, FreePascal is under GPL / L-GPL. Also I guess they wanted something more language specific, as each language has its own “xxxUnit” naming.
I’m with you on the ifdefs!
FPCUnit was originally part of the EOS library. The original author attempted porting DUnit to fpc back in 2003. Eventually he abandoned the effort and created FPCUnit from scratch. Not really sure of the reason he abandoned DUnit. Perhaps it was a technical reason or perhaps the DUnit maintainers weren’t interested in supporting fpc at the time. Craig Peterson, of Scooter Software, made another attempt to port DUnit last year. Not sure what became of it.