Testy jednosto-źródłowe dla Free Pascala i Delphi

Question

Czy istnieje sposób pisania testów jednostkowych, aby można je było skompilować i uruchomić zarówno z Delphi, jak i Free Pascalem?

Istnieją różne schematy testów jednostkowych dla Delphi i Free Pascal, które powodują powielanie pracy dla programistów, którzy kierują swoje działania na oba kompilatory (na przykład programistów bibliotek i frameworków).

Może więc istnieje sposób, używając frameworku DUnit lub FPCUnit i dostroić kod źródłowy przypadku testowego (lub samej struktury), aby działał również z innym kompilatorem.

Więc zasadniczo pytanie brzmi:

• których ramy (DUnit lub FPCUnit) może zostać skompilowany z obu kompilatorów (Delphi i Pascal Free) z jak najmniejszym modyfikacjami, jak to możliwe?

lub

• jest tam trzeci ramy (Dzięki Arnaud dla wspomnieć TSynTest), który współpracuje z Delphi i FPC?

Answer 1

Domyślnie ramy testów jednostkowych dla Free Pascal jest FPCUnit, ma taką samą konstrukcję jak DUnit ale różni się od niej w drobnych szczegółach. Możesz pisać typowe testy jednostkowe dla FPCUnit i DUnit, omijając różnice przez {$IFDEF FPC}. Właśnie przetestowałem FPCUnit, jest to framework użyteczny i blogged about it.

Answer 2

Właśnie bita próbkę, która działa zarówno w DUnit (Delphi) i FPCUnit (FreePascal odpowiednika najbliższego DUnit, że dzieje się już statek „w polu” w Lazarus 1.0, która zawiera FreePascal 2.6):

Trochę banalny IFDEF, a ty tam jesteś.

unit TestUnit1; 

{$IFDEF FPC} 
{$mode objfpc}{$H+} 
{$ENDIF} 

interface 

uses 
    Classes, 
    {$ifdef FPC} 
    fpcunit, testutils, testregistry, 
    {$else} 
    TestFramework, 
    {$endif} 
    SysUtils; 

type 
    TTestCase1= class(TTestCase) 
    published 
    procedure TestHookUp; 
    end; 

implementation 

procedure TTestCase1.TestHookUp; 
begin 
    Self.Check(false,'value'); 
end; 

initialization 
    RegisterTest(TTestCase1{$ifndef FPC}.Suite{$endif}); 
end. 

Answer 3

Zobacz to very nice blog article - tylko świeże mięso o testach FPCUnit.

Krótko mówiąc, o ile wiem, a jeśli compare to DUnit:

• Większość Sprawdź *() metody zostały przemianowane Assert *();
• Metody SetUp/TearDown są nazywane dla funkcji w obu ramach;
• Niektóre inne opinie mogą się różnić.

Tak, myślę, że to może być łatwo pozwolić FPCUnit „naśladuje” DUNIT przez tworząc małe klasy otoki nad wdrażaniem FPCUnit, aby mieć takie same dokładnych metod niż z DUnit. Więc możesz mieć możliwość dzielenia kodu między dwoma celami, a nawet ponownego wykorzystania istniejących testów DUnit. Taką klasą otoki jest IMHO o wiele wygodniejsza niż przy użyciu innych zaleceń. Kompilacja warunkowa powoduje, że kod trudny do debugowania, gadatliwy, nadmiarowy i powinien być używany tylko w razie potrzeby.

Innym potencjalnym rozwiązaniem może być wykorzystanie innych ram testów. Nasz mały TSynTest classes jest lżejszy, ale obecnie konwertuję framework na FPC. Tak więc ten sam dokładny kod mógł być użyty w obu kompilatorach.Ma pewne funkcje (takie jak opcjonalne rejestrowanie z dokładnym profilowaniem i strace w pełnym stosie w przypadku awarii), których brakowałoby mi DUnit/FPCUnit. Nie ma GUI ani czarodzieja, ale szczerze mówiąc, jako programista wolę zwykły tekst, który mogę zawrzeć w mojej dokumentacji technicznego wydania, aby z łatwością potwierdzić, że nie wystąpiła regresja.