test DUnit axée sur les données

Question

La façon dont fonctionne normalement DUnit est que vous écrivez des méthodes publiées et DUnit les exécute comme des tests. Ce que je veux faire est un peu différent. Je veux créer des tests au moment de l'exécution sur la base de données. Je suis en train de tester un module particulier qui traite les fichiers d'entrée pour crée des fichiers de sortie. J'ai un ensemble de fichiers d'entrée de test avec de bons correspondant des fichiers de sortie connus. L'idée est de créer dynamiquement des tests, un pour chaque fichier d'entrée, qui traitent les entrées et vérifier les sorties contre les bons connus.

La source réelle des données ici est cependant pas important. La difficulté fait DUnit se comporter d'une manière axée sur les données. Pour des raisons de ce problème, supposons que la source de données était juste un générateur de nombres aléatoires. Voici un exemple problème concret qui est au cœur de la difficulté:

Créer des objets de test (TTestCase ou autre) lors de l'exécution, soit 10 d'entre eux, où chacun

1. est nommé au moment de l'exécution d'un nombre entier généré de façon aléatoire. (Par « nom », je veux dire le nom du test qui apparaît dans l'arbre test runner.)
2. réussit ou échoue à base d'un nombre entier aléatoire. Pass pour même, pour ne pas bizarre.

De la conception de DUnit, il regarde comme il a été conçu avec suffisamment de flexibilité à l'esprit pour rendre ces choses possibles. Je ne suis pas sûr qu'il est bien. J'ai essayé de créer ma propre classe de test en héritant de TAbstractTest et ITest, mais certaines méthodes cruciales ne sont pas accessibles. J'ai aussi essayé héritant de TTestCase, mais cette classe est étroitement liée à l'idée de courir des méthodes publiées (et les essais sont nommés d'après les méthodes, donc je ne pouvais pas avoir juste un seul appelé, par exemple, « go », parce qu'alors tous mes tests seraient appelés « go », et je veux que tous mes tests pour être nommés individuellement).

Ou bien, est-il une alternative à DUnit qui pourrait faire ce que je veux?

Answer 1

program UnitTest1;

{$IFDEF CONSOLE_TESTRUNNER}
{$APPTYPE CONSOLE}
{$ENDIF}

uses
  Forms, Classes, SysUtils,
  TestFramework,
  GUITestRunner,
  TextTestRunner;

{$R *.RES}

type
  TIntTestCase = class(TTestCase)
  private
    FValue: Integer;
  public
    constructor Create(AValue: Integer); reintroduce;
    function GetName: string; override;
  published
    procedure Run;
  end;

{ TIntTestCase }

constructor TIntTestCase.Create(AValue: Integer);
begin
  inherited Create('Run');
  FValue := AValue;
end;

function TIntTestCase.GetName: string;
begin
  Result := Format('Run_%.3d', [FValue]);
end;

procedure TIntTestCase.Run;
begin
  Check(FValue mod 2 = 0, Format('%d is not an even value', [FValue]));
end;

procedure RegisterTests;
const
  TestCount = 10;
  ValueHigh = 1000;
var
  I: Integer;
begin
  Randomize;
  for I := 0 to TestCount - 1 do
    RegisterTest(TIntTestCase.Create(Random(ValueHigh) + 1));
end;

begin
  Application.Initialize;
  RegisterTests;
  if IsConsole then
    TextTestRunner.RunRegisteredTests
  else
    GUITestRunner.RunRegisteredTests;
end.

Answer 2

Je dirais que vous voulez essentiellement d'avoir une seule fonction « super-test » qui appelle alors d'autres tests, un pour chaque fichier de données. C'est ce que nous faisons avec l'un de nos tests DUnit. Vous venez de charger chaque fichier disponible à son tour dans une boucle, et exécuter le test avec Check de manière appropriée.

L'alternative que nous utilisons dans le même projet pour tester l'application finale et son chargement de données et l'analyse, est d'utiliser quelque chose comme FinalBuilder en boucle sur l'application (boucle probablement vous pourriez sur l'application DUnit aussi, et utiliser un paramètre) avec les différents fichiers de données différentes. L'application fonctionne alors, fait une analyse, puis se ferme après avoir sauvé. Une autre application compare ensuite les données obtenues avec les données idéales, et fait état d'une défaillance le cas échéant.