Тестирование DUnit, управляемое данными

Как обычно работает DUnit, вы пишете некоторые опубликованные методы, а DUnit запускает их как тесты. То, что я хочу сделать, немного отличается. Я хочу создавать тесты во время выполнения на основе данных. Я пытаюсь протестировать определенный модуль, который обрабатывает входные файлы для создания выходных файлов. У меня есть набор тестовых входных файлов с соответствующими хорошими выходными файлами. Идея состоит в том, чтобы динамически создавать тесты, по одному для каждого входного файла, которые обрабатывают входы и проверяют выходы на известные хорошие.

Фактический источник данных здесь, однако, не важен. Трудность заключается в том, что DUnit ведет себя управляемым данными. Для этой проблемы предположим, что источник данных был всего лишь генератором случайных чисел. Вот пример конкретной проблемы, которая доходит до сути проблемы:

Создайте несколько тестовых объектов (TTestCase или что-то еще) во время выполнения, скажем, 10 из них, где каждый

  • Именован во время выполнения из произвольно генерируемого целого числа. (По 'name' я имею в виду имя теста, которое появляется в дереве тестового сервера.)
  • Проходит или не выполняется на основе случайного целого. Передача для четного, сбой для нечетных.

Из дизайна DUnit, похоже, он был разработан с достаточной гибкостью, чтобы сделать такие вещи возможными. Я не уверен, что это правда. Я попытался создать свой собственный тестовый класс, наследуя от TAbstractTest и ITest, но некоторые критические методы были недоступны. Я также пробовал наследовать от TTestCase, но этот класс тесно связан с идеей запуска опубликованных методов (и тесты называются в методах, поэтому я не мог просто написать один, скажем, "идти", потому что тогда все мои тесты будут называться "go", и я хочу, чтобы все мои тесты были индивидуально названы).

Или, альтернативно, есть ли какая-то альтернатива DUnit, которая могла бы делать то, что я хочу?

ОТВЕТЫ

Ответ 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.

Ответ 2

Я бы сказал, что вы в основном хотите иметь одну функцию "супер-тест", которая затем вызывает другие тесты, по одному для каждого файла данных. Это то, что мы делаем с одним из наших тестов DUnit. Вы просто загружаете каждый доступный файл по очереди в цикле и запускаете тест с проверкой по мере необходимости.

Альтернатива, которую мы также используем в том же проекте для тестирования окончательного приложения и его загрузки и анализа данных, заключается в том, чтобы использовать что-то вроде FinalBuilder для цикла в приложении (предположительно, вы могли бы также зацикливать на приложении DUnit и использовать параметр) с различными файлами данных. Затем приложение запускает, выполняет анализ, а затем завершает работу после сохранения. Затем другое приложение сравнивает полученные данные с идеальными данными и сообщает о сбое, если это необходимо.