Delphi中的单元测试-您是如何进行的？

我想知道这里为数不多的Delphi用户是如何进行单元测试的（如果有的话）？您是否发现有任何与IDE集成的东西工作得很好？如果没有，您正在使用什么工具？您是否拥有或知道演示所有工具如何工作的示例小型项目

更新：

---

我忘了提到我使用的是BDS 2006 Pro，虽然我偶尔会使用Delphi 7，当然其他人可能会使用其他版本。

是一种xUnit类型的单元测试框架，用于win32 Delphi。自Delphi 2005以来，DUnit被集成到IDE的某个特定点。可以找到DelphiIDE的其他DUnit集成工具。DUnit随附。

我们尝试将DUnit与Delphi 5结合使用，但效果不佳。特别是，如果您正在实现COM接口，我们发现许多依赖项用于设置所有测试基础结构。我不知道新版本中的测试支持是否有所改进。

通常我创建一个单元测试项目（文件->新建->其他->单元测试->测试项目）。它包含了我需要的东西，所以到目前为止已经足够好了

---

我使用delphi 2007，因此我不知道它是否在2006年可用。

我们使用DUnit对所有逻辑代码进行单元测试，并使用中包含的代码覆盖率分析器检查通过代码的所有路径是否由测试执行。

DUnit2可从

DUnit2比原始dunit更经常地修改。它也适用于Delphi 2009

---

试一试：-当原作者彼得·麦克纳布几年前去世时，它感动了。dunit邮件列表上还有一些活动。

dunit还有一些附加功能，也许这值得一个新条目。我现在可以列在清单上的两个是

集成：单元测试将自动检测内存泄漏（和其他事情），与DUnit 9.3及更新版本配合使用

是"组件测试" 基于DUnit的框架，it 动态创建的测试 项目中的所有组件 表单、框架和数据模块，以及 使用自定义规则测试它们（开源）

---

我们有两种方法，首先是由开发人员运行的Dunit测试，这些测试确保刚刚更改的代码仍然像以前一样工作。另一种方法是使用CruiseControl.NET构建可执行文件，然后在每次进行更改时运行dunit测试，以确保更改不会产生意外后果

---

我们的许多代码库都没有测试，因此自动测试是一个持续开发的案例，以确保我们的应用程序按照我们认为应该的方式工作。

您可以查看我们的应用程序中可用的单元测试类。它在我们的开源框架中用于所有回归测试。这也许不是最好的，但值得一看

看

为了实现单元测试，您只需通过创建如下类来声明一个新的测试用例：

type
  TTestNumbersAdding = class(TSynTestCase)
  published
    procedure TestIntegerAdd;
    procedure TestDoubleAdd;
  end;

procedure TTestNumbersAdding.TestDoubleAdd;
var A,B: double;
    i: integer;
begin
  for i := 1 to 1000 do
  begin
    A := Random;
    B := Random;
    CheckSame(A+B,Adding(A,B));
  end;
end;

然后创建一个测试套件，并运行它

在即将发布的1.13版本中，还有一种新的日志记录机制，可以跟踪任何引发的异常，就像MadExcept一样，使用.map文件内容作为源

单元测试类现在使用它，因此任何故障都会在日志中创建一个条目，其中包含源代码行和堆栈跟踪：

C:\Dev\lib\SQLite3\exe\TestSQL3.exe 0.0.0.0 (2011-04-13)
Host=Laptop User=MyName CPU=2*0-15-1027 OS=2.3=5.1.2600 Wow64=0 Freq=3579545
TSynLogTest 1.13 2011-04-13 05:40:25

20110413 05402559 fail  TTestLowLevelCommon(00B31D70) Low level common: TDynArray "" stack trace 0002FE0B SynCommons.TDynArray.Init (15148) 00036736 SynCommons.Test64K (18206) 0003682F SynCommons.TTestLowLevelCommon._TDynArray (18214) 000E9C94 TestSQL3 (163) 

没有日志记录的测试服和有日志记录的测试服之间的区别仅在于：

procedure TSynTestsLogged.Failed(const msg: string; aTest: TSynTestCase);
begin
  inherited;
  with TestCase[fCurrentMethod] do
    fLogFile.Log(sllFail,'%: % "%"',
      [Ident,TestName[fCurrentMethodIndex],msg],aTest);
end;

日志机制可以做的不仅仅是记录测试：您可以记录方法的递归调用，选择要显示在日志中的信息，从客户端分析应用程序，将发布的属性、TList或TCollection内容作为JSON写入日志内容，等等

第一次读取.map文件时，将创建一个.mab文件，该文件将包含所需的所有符号信息。您可以将带有.exe的.mab文件发送到客户端，甚至可以将其内容嵌入到.exe中。该.mab文件经过优化：927984字节的.map压缩为71943.mab文件

因此，在纯开源软件中，这个单元可以被认为是DUnit和Madding的亲生子女

---

其他信息如下所示。请随便问。欢迎反馈和功能请求！从Delphi6到XE都可以使用。

开发中有一个新的单元测试框架，用于现代Delphi版本：

+1。。。绝对值得更新，这就是所谓的：）+1链接：+1链接。我的项目需要很长时间才能上市，因此我不想在这个过程中再添加任何步骤。我越来越接近我认为关键的质量，我想实现一个测试过程。这可能是其中的一部分。+1很好，听起来很值得一看：）在github中再也找不到存储库了。虽然我将这作为公认的答案，但请参阅下面的Harrisv最新更新（2013年10月）。正确测试软件没有自动替换，除非要测试的软件已经过时，并且没有进一步的开发（通常软件更改为fast，以便测试程序/单元跟上）。测试程序本身可能包含bug。我自己为我写的所有东西编写迷你测试程序。。。它没有替代品。作为一名测试人员将是一份很好的工作保障，它永远不会消失；）就我而言，“单元测试框架”是完全无用的。简单地调用所有的方法并手动地通过它是调试的最佳方法。与上面提到的“SkyBukF飞”相反，自动化单元测试是正确测试软件的基础。适当的自动化单元测试可以实现松耦合和良好的设计。“我自己为我所写的一切编写小型测试程序……没有替代品。”这正是单元测试框架的含义——一个用于编写简单测试程序的框架，确保给定代码按预期运行，并以一致和自动化的方式报告结果。当我想到“测试”时，我想到了“调试”，什么