我承认我几乎没有单元测试经验。我刚才尝试使用DUnit，但放弃了，因为我的应用程序中的类之间存在很多依赖关系。 它是一个相当大的（大约150万个源代码行）Delphi应用程序，我们是一个维护它的团队。
现在的测试是由一个在发布之前使用它并报告错误的人完成的。我还在TestComplete 6中设置了一些GUI测试，但由于应用程序的更改，它经常失败。
Bold for Delphi用作数据库的持久性框架。 我们都同意单元测试是要走的路，我们计划在DotNet中编写一个新的应用程序，ECO作为持久性框架。
我只是不知道从哪里开始进行单元测试...... 任何好书，网址，最佳实践等？
答案 0 :(得分：12)
嗯，单元测试的挑战不是测试本身，而是编写可测试代码。如果代码写的是而不是考虑测试，那么你可能会非常困难。
无论如何，如果你可以重构，请重构以使其可测试。尽可能不要将对象创建与逻辑混合（我不知道delphi，但可能有一些依赖注入框架来帮助实现）。
This blog对测试有很多很好的见解。例如，检查this article（我的第一个建议是基于它）。
至于建议，首先尝试测试代码的叶节点，这些类不依赖于其他类。它们应该更容易测试，因为它们不需要模拟。
答案 1 :(得分：8)
为遗留代码编写单元测试通常需要大量重构。 涵盖这一点的优秀书籍是Michael Feather的“有效地使用遗留代码”
另外一个建议：使用单元测试覆盖率工具来指示您在此工作中的进度。我不确定Delphi代码的良好覆盖工具是什么。我想这将是一个不同的问题/主题。
答案 2 :(得分：3)
一种比较流行的方法是在修改代码时编写单元测试。所有新代码都进行单元测试，对于您修改的任何代码，您首先编写测试，验证，修改，重新验证，然后编写/修复因修改而需要的任何测试。
拥有良好的单元测试覆盖率的一大优势是能够验证您所做的更改不会无意中破坏其他内容。这种方法可以帮助您实现这一目标，同时将精力集中在您的直接需求上。
我采用的替代方法是通过Co-Ops开发我的单元测试：）
答案 3 :(得分：3)
使用遗留代码时，模拟对象对构建单元测试非常有用。
看看有关Delphi和模拟的问题：What is your favorite Delphi mocking library?
答案 4 :(得分：1)
对于.Net unittesting，请阅读：“单元测试的艺术：使用.NET中的示例”
关于最佳实践：
你所说的是对的：有时，由于类之间的依赖性，很难编写单元测试...
所以在之后或之前写单元测试;-)类的实现。像这样，如果您在编写测试时遇到一些困难，也许这意味着您遇到了设计问题！