我承认我几乎没有单元测试的经验。前一段时间，我尝试过使用DUnit，但放弃了，因为在我的应用程序中类之间有太多依赖关系。 这是一个相当大的（约150万源代码行）Delphi应用程序，我们是一个维护它的团队。如何启动单元测试旧代码和新代码？
现在的测试是由一个人在发布和报告错误之前使用它来完成的。我还在TestComplete 6中设置了一些GUI测试，但由于应用程序的变化，它经常失败。
德尔福的Bold用作针对数据库的持久性框架。 我们都同意单元测试是一条路，我们计划在DotNet中使用ECO作为持久性框架编写一个新的应用程序。
我只是不知道从哪里开始单元测试... 任何好书，网址，最佳实践等？
那么，单元测试的挑战不在于测试本身，而是在编写可测试代码。如果代码被写入而不是考虑测试，那么你可能会非常难过。
无论如何，如果你可以重构，做重构使其可测试。尽可能不要将对象创建与逻辑混合在一起（我不知道delphi，但可能有一些依赖注入框架可以帮助实现此目的）。
This blog对测试有很多很好的见解。例如检查this article（我的第一个建议是基于它）。
至于一个建议，先尝试测试你的代码的叶节点，那些不依赖于别人的类。他们应该更容易测试，因为他们不需要嘲笑。
其中一种比较流行的方法是在修改代码时编写单元测试。所有新代码都会进行单元测试，对于您修改的任何代码，首先编写测试，验证，修改，重新验证，然后编写/修复由于修改而需要的任何测试。
具有良好的单元测试覆盖率的一大优势是能够验证您所做的更改不会无意中破坏别的东西。这种方法可以让您做到这一点，同时将您的努力集中在您的直接需求上。
我所采用的另一种方法是通过合作社:)
编写单元测试的遗留代码来开发我的单元测试通常需要大量的重构。 覆盖这本优秀著作是迈克尔羽毛的“修改代码有效地开展工作”
一个额外的建议：使用单元测试覆盖率工具指明这项工作的进度。我不确定Delphi代码的优秀覆盖工具是什么。我想这将是一个不同的问题/主题。
对于.NET单元测试阅读： “单元测试的艺术：在.NET示例”
关于最佳pratices：
你说的是对的：有时，它是难以编写单元测试，因为类之间的依赖关系...因此，编写单元测试只是在之后或之前;-)类的实现。像这样，如果你在编写测试时遇到一些困难，也许这意味着你有一个设计问题！
是的，编写遗留代码的单元测试通常很困难。但是你可能会重构你的代码。有许多书籍可以说明这一点，Michael Feather的“与遗产代码有效地合作”是一本极好的书籍。 – 2009-07-17 17:09:13
当您使用遗留代码时，mock objetcs对构建单元测试非常有用。
看看关于德尔福这个问题，并嘲笑：What is your favorite Delphi mocking library?
是的，这是圣杯，做出更大的变化，而不用担心当它看起来确定打破任何东西。 – 2009-07-17 11:07:30