我在一个名为Utils.pas
.
现在我想重构其中的一些,但我认为最好先编写测试。对于 DUnit,我认为没有课程是不可能的。
所以我想知道在重构之前如何测试它们?
编辑:
我认为这是不可能的,因为我试图使用测试用例向导在 Delphi 中添加一个测试用例。看下图,没有任何类和方法,所以我无法创建它。
我在一个名为Utils.pas
.
现在我想重构其中的一些,但我认为最好先编写测试。对于 DUnit,我认为没有课程是不可能的。
所以我想知道在重构之前如何测试它们?
编辑:
我认为这是不可能的,因为我试图使用测试用例向导在 Delphi 中添加一个测试用例。看下图,没有任何类和方法,所以我无法创建它。
AFAICT,DUnit 不需要被测代码作为类方法存在。只有测试用例本身必须是类。
编辑:向导只是一种方便。你不必使用它。
您无法使用向导测试独立函数,但使用 DUnit 测试独立函数不是问题。
例子
//***** A Standalone function te be tested in a unit far, far away
function Add(v1, v2: Integer): Integer;
...
//***** A testclass to contain the testmethods calling our
// standalone function
TTestAdd = class(TTestcase)
published
procedure AddingComplement_ShouldEqualZero;
procedure AddingNegativeNumbers_ShouldBeLessThanZero
...
end;
implementation
procedure TTestAdd.AddingComplement_ShouldEqualZero;
begin
// Setup, Execute & Verify
CheckEquals(0, Utils.Add(-1, 1), 'Complement doesn''t add to zero');
end;
procedure TTestAdd.AddingNegativeNumbers_ShouldBeLessThanZero
begin
// Setup, Execute & Verify
CheckEquals(-3, Utils.Add(-1, -2), 'Add doesn''t add');
end;
需要维护真正的代码。真实的代码有一些没有很好记录的假设。真正的代码是由忘记或不知道这些假设的人更改的。相信测试,不要相信代码。
真正的 TDD 允许您在实现之前创建对象及其方法。在编写测试用例之前,您需要一个清晰的模型。
所以生成对象,添加方法,参数等。可能最好使用UML2,然后为这些编写测试用例,然后实现对象。之后运行分析器并找出你的代码到底有多糟糕,然后重构。
作为一般解决方案,几乎总是最好编写一个工厂对象来实例化和初始化您的对象。越接近核心功能,这就越重要。
为您预期的失败和异常编写测试。使用支票来确定。
最后编写每个测试并观察它是否失败,然后再编写代码以使其成功。