Test di unità a sorgente singola per Free Pascal e Delphi

Question

C'è un modo per scrivere test di unità in modo che possano essere compilati ed eseguiti sia con Delphi che con Free Pascal?

Esistono diversi framework di test unitari per Delphi e Free Pascal, che creano un lavoro duplicato per gli sviluppatori che hanno come target sia i compilatori (ad esempio, gli sviluppatori di librerie e framework).

Quindi forse c'è un modo, utilizzando il DUnit o il framework FPCUnit e modificare il codice sorgente del caso di test (o il framework stesso) in modo che funzioni anche con l'altro compilatore.

Quindi, in sostanza la domanda è:

• cui quadro (dunit o FPCUnit) possono essere compilati con entrambi i compilatori (Delphi e Free Pascal) con il minor numero possibile di modifiche?

o

• c'è un terzo quadro (Grazie a Arnaud per menzionare TSynTest) che funziona con Delphi e FPC?

Answer 1

predefinito quadro unit test per Free Pascal è FPCUnit, ha lo stesso design dunit ma diverso da esso in dettagli minori. È possibile scrivere test unitari comuni per FPCUnit e DUnit eludendo le differenze per {$IFDEF FPC}. Ho appena testato FPCUnit, è un framework utilizzabile e blogged about it.

Answer 2

ho montata su un campione che funziona sia dunit (Delphi) e FPCUnit (equivalente Freepascal più vicina a dunit, che avviene per la spedizione già "nella casella" in Lazarus 1.0, che include FreePascal 2.6):

Un bit banale di IFDEF e ci sei.

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

Vedere questo very nice blog article - solo carne fresca su test FPCUnit.

Insomma, per quanto ne so, e se si compare to DUnit:

• maggior Controllo *() metodi sono stati rinominati Assert *();
• I metodi SetUp/TearDown sono chiamati per funzione in entrambi i framework;
• Alcuni altri possono variare.

Quindi, penso che potrebbe essere facile lasciare FPCUnit "imita" dunit, da creando una piccola classe wrapper sull'esecuzione FPCUnit, di avere gli stessi metodi esatti che con dunit. Quindi potresti essere in grado di condividere il codice tra i due obiettivi e persino riutilizzare i test DUnit esistenti. Una tale classe di wrapper è IMHO molto più comoda rispetto all'uso di {$ifdef FPC} come suggerito qui. La compilazione condizionale tende a rendere il codice difficile da eseguire il debug, dettagliato, ridondante e dovrebbe essere utilizzato solo se necessario.

Un'altra possibile soluzione potrebbe essere quella di utilizzare altri framework di test. Il nostro piccolo TSynTest classes è più leggero, ma attualmente sto convertendo il framework in FPC. Quindi lo stesso identico codice potrebbe essere usato con entrambi i compilatori.Ha alcune caratteristiche (come la registrazione facoltativa con profilazione fine e lo stack completo in caso di errore) che mi mancherebbero da DUnit/FPCUnit. Non ha una GUI o un Wizard ma onestamente, in quanto programmatore preferisco il semplice testo che posso includere nella documentazione di rilascio tecnico facilmente per testimoniare che non si è verificata alcuna regressione.