delphi - test - ¿Puedo escribir pruebas ''parametrizadas'' en DUnit?

test en java

Question

Estoy usando DUnit para probar una biblioteca de Delphi. A veces me topo con casos en los que escribo varias pruebas muy similares para verificar entradas múltiples a una función.

¿Hay alguna manera de escribir (algo parecido) una prueba parametrizada en DUnit? Por ejemplo, especificar una entrada y un resultado esperado para un procedimiento de prueba adecuado, luego ejecutar el conjunto de pruebas y obtener retroalimentación sobre cuál de las múltiples ejecuciones de la prueba falló.

(Editar: un ejemplo)

Por ejemplo, supongamos que tengo dos pruebas como esta:

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;

Podría tener aún más de estas pruebas que hacen exactamente lo mismo pero con diferentes entradas y expectativas. No quiero fusionarlos en una sola prueba, porque me gustaría que pasen o fallen de forma independiente.

Answer 1

¿Sería suficiente si DUnit permitiera escribir código como este, donde cada llamada de AddTestForDoStuff crearía un caso de prueba similar a los de su ejemplo?

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

Trataré de publicar un ejemplo de cómo se puede hacer más tarde hoy ...

Para .Net ya hay algo similar: Afirmaciones fluidas

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

Answer 2

Aquí hay un ejemplo del uso de un método de prueba parametrizado general llamado desde los métodos de prueba reales (publicados) de los descendientes de TTestCase (:

procedure TTester.CreatedWithoutDisplayFactorAndDisplayString;
begin
MySource := TMyClass.Create(cfSum);
SendAndReceive;
CheckDestinationAgainstSource;
end;
procedure TTester.CreatedWithDisplayFactorWithoutDisplayString;
begin
MySource := TMyClass.Create(cfSubtract, 10);
SendAndReceive;
CheckDestinationAgainstSource;
end;

Sí, hay algo de duplicación, pero la duplicación principal del código se tomó de estos métodos en los métodos SendAndReceive y CheckDestinationAgainstSource en una clase antepasado:

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;

El parámetro en CheckDestinationAgainstSource también permite este tipo de uso:

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;

Esta última prueba también podría codificarse usando la clase TRepeatedTest, pero creo que esa clase no es muy intuitiva de usar. El código anterior me da una mayor flexibilidad para codificar verificaciones y producir mensajes de falla inteligibles. Sin embargo, tiene el inconveniente de detener la prueba en la primera falla.

Answer 3

Creo que estás buscando algo como esto:

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.

que se ve así en el corredor de prueba GUI:

Estaría muy interesado en saber si he hecho esto de una manera subóptima. DUnit es tan increíblemente general y flexible que siempre que lo uso, siempre termino sintiendo que me he perdido una manera mejor y más simple de resolver el problema.

Answer 4

Puede usar DSharp para mejorar sus pruebas de DUnit. Especialmente la nueva unidad DSharp.Testing.DUnit.pas (en Delphi 2010 y superior).

Solo agréguela a sus usos después de TestFramework y puede agregar atributos a su caso de prueba. Entonces podría verse así:

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.

Cuando lo ejecutas, tu prueba se ve así:

Como los atributos en Delphi solo aceptan constantes, los atributos simplemente toman los argumentos como una cadena donde los valores están separados por un punto y coma. Pero nada le impide crear sus propias clases de atributos que toman múltiples argumentos del tipo correcto para evitar cadenas "mágicas". De todos modos, estás limitado a tipos que pueden ser const.

También puede especificar el atributo de Valores en cada argumento del método y se llama con cualquier combinación posible (como en NUnit ).

Al referirme a las otras respuestas personalmente, quiero escribir la menor cantidad de código posible al escribir pruebas unitarias. También quiero ver lo que hacen las pruebas cuando miro la parte de la interfaz sin profundizar en la parte de implementación (no voy a decir: "hagamos BDD "). Es por eso que prefiero la forma declarativa.