Тестирование 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 и использовать параметр) с различными файлами данных. Затем приложение запускает, выполняет анализ, а затем завершает работу после сохранения. Затем другое приложение сравнивает полученные данные с идеальными данными и сообщает о сбое, если это необходимо.