我正在使用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;
我可能会有更多这些测试做同样的事情,但有不同的输入和期望。我不想将它们合并到一个测试中,因为我希望它们能够独立通过或失败。
答案 0 :(得分:19)
您可以使用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中的属性只接受常量,因此属性只将参数作为字符串,其中值以分号分隔。但是没有什么能阻止你创建自己的属性类,这些属性类采用正确类型的多个参数来防止“魔术”字符串。无论如何,你只限于可以是const的类型。
您还可以在方法的每个参数上指定Values属性,并使用任何可能的组合调用它(如NUnit中所示)。
在编写单元测试时,我个人想要编写尽可能少的代码。另外,我想看看测试在没有深入了解实现部分的情况下查看接口部分时会做什么(我不会说:“让我们做BDD”)。这就是为什么我更喜欢陈述性的方式。
答案 1 :(得分:13)
我认为你正在寻找这样的东西:
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测试运行器中看起来像这样:
我很想知道我是否以次优的方式解决了这个问题。 DUnit是如此令人难以置信的一般性和灵活性,每当我使用它时,我总觉得我错过了一种更好,更简单的方法来解决问题。
答案 2 :(得分:3)
如果DUnit允许编写这样的代码就足够了,其中AddTestForDoStuff的每次调用都会创建一个与你的例子类似的测试用例?
Suite.AddTestForDoStuff.With(2).Expect(4);
Suite.AddTestForDoStuff.With(3).Expect(9);
我试着发布一个例子,说明今天晚些时候可以做到这一点......
对于.Net,已经有类似的东西:Fluent Assertions
http://www.codeproject.com/Articles/784791/Introduction-to-Unit-Testing-with-MS-tests-NUnit-a
答案 3 :(得分:0)
以下是使用从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类进行编码,但我发现该类使用起来相当不直观。上面的代码为编码检查和生成可理解的失败消息提供了更大的灵活性。然而,它确实存在在第一次失败时停止测试的缺点。