Могу ли я написать «параметризованные» тесты в DUnit

Question

Я использую DUnit для тестирования библиотеки Delphi.Иногда я сталкиваюсь со случаями, когда я пишу несколько очень похожих тестов для проверки нескольких входов в функцию.

Есть ли способ написать (что-то похожее) параметризованный тест в DUnit?Например, указание ввода и ожидаемого вывода в подходящей процедуре тестирования, затем запуск набора тестов и получение обратной связи о том, какой из нескольких прогонов теста не удался?

(Редактировать: пример)

Например, предположим, что у меня было два таких теста:

procedure TestMyCode_WithInput2_Returns4();
var
  Sut: TMyClass;
  Result: Integer;
begin
  // Arrange:
  Sut := TMyClass.Create;

  // Act:
  Result := sut.DoStuff(2);

  // Assert
  CheckEquals(4, Result);
end;

procedure TestMyCode_WithInput3_Returns9();
var
  Sut: TMyClass;
  Result: Integer;
begin
  // Arrange:
  Sut := TMyClass.Create;

  // Act:
  Result := sut.DoStuff(3);

  // Assert
  CheckEquals(9, Result);
end;

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

Answer 1

Вы можете использовать DSharp для улучшения ваших тестов DUnit. Особенно новый блок DSharp.Testing.DUnit.pas (в Delphi 2010 и выше).

Просто добавьте его к своему использованию после TestFramework, и вы сможете добавить атрибуты в ваш тестовый пример. Тогда это может выглядеть так:

unit MyClassTests;

interface

uses
  MyClass,
  TestFramework,
  DSharp.Testing.DUnit;

type
  TMyClassTest = class(TTestCase)
  private
    FSut: TMyClass;
  protected
    procedure SetUp; override;
    procedure TearDown; override;
  published
    [TestCase('2;4')]
    [TestCase('3;9')]
    procedure TestDoStuff(Input, Output: Integer);
  end;

implementation

procedure TMyClassTest.SetUp;
begin
  inherited;
  FSut := TMyClass.Create;
end;

procedure TMyClassTest.TearDown;
begin
  inherited;
  FSut.Free;
end;

procedure TMyClassTest.TestDoStuff(Input, Output: Integer);
begin
  CheckEquals(Output, FSut.DoStuff(Input));
end;

initialization
  RegisterTest(TMyClassTest.Suite);

end.

Когда вы запустите его, ваш тест будет выглядеть так:

Поскольку атрибуты в Delphi просто принимают константы, атрибуты просто принимают аргументы в виде строки, где значения разделяются точкой с запятой. Но ничто не мешает вам создавать свои собственные классы атрибутов, которые принимают несколько аргументов правильного типа для предотвращения «магических» строк. В любом случае вы ограничены типами, которые могут быть постоянными.

Вы также можете указать атрибут Values ​​для каждого аргумента метода, и он вызывается с любой возможной комбинацией (как в NUnit ).

Обращаясь лично к другим ответам, я хочу написать как можно меньше кода при написании модульных тестов. Также я хочу посмотреть, что делают тесты, когда я смотрю на интерфейсную часть, не копаясь в части реализации (я не собираюсь говорить: «давайте сделаем BDD »). Вот почему я предпочитаю декларативный способ.

Answer 2

Я думаю, вы ищете что-то вроде этого:

unit TestCases;

interface

uses
  SysUtils, TestFramework, TestExtensions;

implementation

type
  TArithmeticTest = class(TTestCase)
  private
    FOp1, FOp2, FSum: Integer;
    constructor Create(const MethodName: string; Op1, Op2, Sum: Integer);
  public
    class function CreateTest(Op1, Op2, Sum: Integer): ITestSuite;
  published
    procedure TestAddition;
    procedure TestSubtraction;
  end;

{ TArithmeticTest }

class function TArithmeticTest.CreateTest(Op1, Op2, Sum: Integer): ITestSuite;
var
  i: Integer;
  Test: TArithmeticTest;
  MethodEnumerator: TMethodEnumerator;
  MethodName: string;
begin
  Result := TTestSuite.Create(Format('%d + %d = %d', [Op1, Op2, Sum]));
  MethodEnumerator := TMethodEnumerator.Create(Self);
  Try
    for i := 0 to MethodEnumerator.MethodCount-1 do begin
      MethodName := MethodEnumerator.NameOfMethod[i];
      Test := TArithmeticTest.Create(MethodName, Op1, Op2, Sum);
      Result.addTest(Test as ITest);
    end;
  Finally
    MethodEnumerator.Free;
  End;
end;

constructor TArithmeticTest.Create(const MethodName: string; Op1, Op2, Sum: Integer);
begin
  inherited Create(MethodName);
  FOp1 := Op1;
  FOp2 := Op2;
  FSum := Sum;
end;

procedure TArithmeticTest.TestAddition;
begin
  CheckEquals(FOp1+FOp2, FSum);
  CheckEquals(FOp2+FOp1, FSum);
end;

procedure TArithmeticTest.TestSubtraction;
begin
  CheckEquals(FSum-FOp1, FOp2);
  CheckEquals(FSum-FOp2, FOp1);
end;

function UnitTests: ITestSuite;
begin
  Result := TTestSuite.Create('Addition/subtraction tests');
  Result.AddTest(TArithmeticTest.CreateTest(1, 2, 3));
  Result.AddTest(TArithmeticTest.CreateTest(6, 9, 15));
  Result.AddTest(TArithmeticTest.CreateTest(-3, 12, 9));
  Result.AddTest(TArithmeticTest.CreateTest(4, -9, -5));
end;

initialization
  RegisterTest('My Test cases', UnitTests);

end.

, который выглядит так в GUI Test Runner:

Мне было бы очень интересно узнать, поступил ли я об этом неоптимальным образом. DUnit настолько невероятно универсален и гибок, что всякий раз, когда я его использую, я всегда чувствую, что упустил лучший, более простой способ решения проблемы.

Answer 3

Было бы достаточно, если бы DUnit позволял писать код, подобный этому, где каждый вызов AddTestForDoStuff будет создавать тестовый пример, аналогичный приведенному в вашем примере?

Suite.AddTestForDoStuff.With(2).Expect(4);
Suite.AddTestForDoStuff.With(3).Expect(9);

Я постараюсь опубликовать примеркак это можно сделать позже сегодня ...

---

Для .Net уже есть нечто подобное: Свободные утверждения

http://www.codeproject.com/Articles/784791/Introduction-to-Unit-Testing-with-MS-tests-NUnit-a

Answer 4

Вот пример использования общего параметризованного метода тестирования, вызываемого из ваших фактических (опубликованных) методов тестирования потомков TTestCase (:

procedure TTester.CreatedWithoutDisplayFactorAndDisplayString;
begin
  MySource := TMyClass.Create(cfSum);

  SendAndReceive;
  CheckDestinationAgainstSource;
end;

procedure TTester.CreatedWithDisplayFactorWithoutDisplayString;
begin
  MySource := TMyClass.Create(cfSubtract, 10);

  SendAndReceive;
  CheckDestinationAgainstSource;
end;

Да, есть некоторое дублирование, но основное дублирование кода былоизвлеченные из этих методов в методы SendAndReceive и CheckDestinationAgainstSource в классе предков:

procedure TCustomTester.SendAndReceive;
begin
  MySourceBroker.CalculationObject := MySource;
  MySourceBroker.SendToProtocol(MyProtocol);
  Check(MyStream.Size > 0, 'Stream does not contain xml data');
  MyStream.Position := 0;
  MyDestinationBroker.CalculationObject := MyDestination;
  MyDestinationBroker.ReceiveFromProtocol(MyProtocol);
end;

procedure TCustomTester.CheckDestinationAgainstSource(const aCodedFunction: string = '');
var
  ok: Boolean;
  msg: string;
begin
  if aCodedFunction = '' then
    msg := 'Calculation does not match: '
  else
    msg := 'Calculation does not match. Testing CodedFunction ' + aCodedFunction + ': ';

  ok := MyDestination.IsEqual(MySource, MyErrors);
  Check(Ok, msg + MyErrors.Text);
end;

Параметр в CheckDestinationAgainstSource также допускает использование этого типа:

procedure TAllTester.AllFunctions;
var
  CF: TCodedFunction;
begin
  for CF := Low(TCodedFunction) to High(TCodedFunction) do
  begin
    TearDown;
    SetUp;
    MySource := TMyClass.Create(CF);
    SendAndReceive;
    CheckDestinationAgainstSource(ConfiguredFunctionToString(CF));
  end;
end;

Этот последний тесттакже может быть закодирован с использованием класса TRepeatedTest, но я считаю, что этот класс довольно не интуитивно понятен. Приведенный выше код дает мне большую гибкость при проверке кодирования и создании понятных сообщений об ошибках. Однако он имеет недостаток - останавливать тест при первом сбое.