你可以使用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）。
就我个人而言，我想在编写单元测试时尽可能少地编写代码。此外，我想看看当我查看接口部分而不深入实现部分时测试会做什么（我不会说：“let's do BDD“）。这就是为什么我更喜欢声明式的方式。

我想你正在寻找这样的东西：

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是如此的通用和灵活，以至于每当我使用它时，我总是觉得我错过了一种更好、更简单的解决问题的方法。

如果DUnit允许编写这样的代码，即每次调用AddTestForDoStuff都会创建一个类似于您的示例中的测试用例，这就足够了吗？

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

我将尝试张贴一个例子如何这可以做到今天晚些时候...
对于.Net，已经有类似的东西：流利的Assert
http://www.codeproject.com/Articles/784791/Introduction-to-Unit-Testing-with-MS-tests-NUnit-a

下面是一个使用通用参数化测试方法的示例，该方法从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类进行编码，但我发现该类使用起来相当不直观。上面的代码在编码检查和生成可理解的失败消息方面给了我更大的灵活性。然而，它确实有在第一次失败时停止测试的缺点。

至少在 Delphi XE8中，刚开箱即用的DUnitX具有类似的属性：

[TestCase('Test1', '1,one')]
[TestCase('Test2', '2,two')]
procedure TestIntToStr(AValInt: Integer; const AValString: string);

(See也称为https://docwiki.embarcadero.com/RADStudio/Seattle/en/DUnitX_Overview和https://web.archive.org/web/20150504232249/http://docwiki.embarcadero.com/RADStudio/XE8/en/DUnitX_Overview）
它也可用于 Delphi 从2010年版本在https://github.com/VSoftTechnologies/DUnitX