18

我承认我几乎没有单元测试的经验。不久前我尝试过使用 DUnit，但由于我的应用程序中的类之间存在太多依赖关系而放弃了。这是一个相当大的（大约 150 万行源代码）Delphi 应用程序，我们是一个维护它的团队。

目前的测试是由一个在发布前使用它并报告错误的人完成的。我还在 TestComplete 6 中设置了一些 GUI 测试，但由于应用程序的更改，它经常失败。

Delphi 的 Bold 用作针对数据库的持久性框架。我们都同意单元测试是要走的路，我们计划用 ECO 作为持久性框架在 DotNet 中编写一个新的应用程序。

我只是不知道从哪里开始进行单元测试...有什么好书、URL、最佳实践等吗？

4

5 回答 5

13

嗯，单元测试的挑战不是测试本身，而是编写可测试的代码。如果编写代码时没有考虑测试，那么您可能会遇到困难。

无论如何，如果您可以重构，请进行重构以使其可测试。尽可能不要将对象创建与逻辑混为一谈（我不知道 delphi，但可能有一些依赖注入框架可以帮助解决这个问题）。

这个博客对测试有很多很好的见解。例如检查这篇文章（我的第一个建议是基于它）。

至于建议，请先尝试测试代码的叶节点，即那些不依赖其他类的类。它们应该更容易测试，因为它们不需要模拟。

于 2009-07-16T12:30:45.120 回答
8

为遗留代码编写单元测试通常需要大量重构。涵盖这方面的优秀书籍是 Michael Feather 的“有效地使用遗留代码”

另一个建议：使用单元测试覆盖率工具来表明您在这项工作中的进度。不过，我不确定 Delphi 代码的良好覆盖工具是什么。我想这将是一个不同的问题/主题。

有效地使用遗留代码

于 2009-07-16T12:28:59.973 回答
3

一种更流行的方法是在修改代码时编写单元测试。所有新代码都会进行单元测试，对于您修改的任何代码，您首先编写它的测试，验证它，修改它，重新验证它，然后编写/修复由于您的修改而需要的任何测试。

具有良好的单元测试覆盖率的一大优势是能够验证您所做的更改不会无意中破坏其他内容。这种方法使您可以做到这一点，同时将精力集中在您的迫切需求上。

我采用的替代方法是通过 Co-Ops 开发我的单元测试 :)

于 2009-07-16T12:27:59.847 回答
3

当您使用遗留代码时，模拟对象对于构建单元测试非常有用。

看看这个关于 Delphi 和 mocks 的问题：你最喜欢的 Delphi 模拟库是什么？

于 2010-04-01T20:35:36.743 回答
1

对于 .Net 单元测试，请阅读：“单元测试的艺术：.NET 中的示例”

关于最佳实践：
您说的是对的：有时，由于类之间的依赖关系，很难编写单元测试......所以在类的实现之后或之前编写单元测试；-) 类的实现。像这样，如果你在编写测试时遇到一些困难，也许这意味着你有一个设计问题！

于 2009-07-16T12:29:21.267 回答