c# - 为单元测试做好编码准备的最佳策略

Question

我有一个缺少很多代码覆盖率的解决方案。我需要重构此代码以解耦以开始创建单元测试。什么是最好的策略？我首先认为我应该推动将业务逻辑与来自业务对象的数据访问分离，以首先获得一些组织，然后从那里向下钻取。由于许多类不支持单一责任原则，因此很难开始测试它们。

是否有其他建议或最佳实践来采用遗留解决方案并将其成型以准备好进行代码覆盖和单元测试？

score 10 · Accepted Answer

10

于 2008-11-25T11:39:38.923 回答

score 4 · Accepted Answer

在遗留代码中要做的最重要的事情之一和处理遗留代码的最佳方法是缺陷。这是一个您将继续使用您引入单元测试的任何代码库的过程。每当报告缺陷时，编写一个单元测试来暴露该缺陷。您会很快发现会定期中断的代码（即“哦，耶。xyzzy 类中的plugh() 方法又被破坏了！）将开始越来越少地中断。

真的，开始做吧。您不会在一夜之间在遗留应用程序中获得大量覆盖。首先点击更容易损坏的代码，然后开始分支。确保代码中的任何新开发也具有更高的代码覆盖率。

请记住，TDD 的口号是“红/绿/重构”，您可能希望研究重构工具来帮助完成一些随之而来的乏味任务。JetBrain 的ReSharper很受欢迎，也是我个人的选择。

score 1 · Accepted Answer

1

从创建测试开始。根据需要重构代码以支持测试。

于 2008-11-25T12:01:06.477 回答

score 1 · Accepted Answer

我建议首先为现有代码创建测试，直到你有足够的覆盖率。您需要按原样测试您的代码，以确保在重构时不会破坏任何内容。当然，你会想要一块一块地做，为一个模块编写测试，然后在继续下一个之前重构它。一旦获得了良好的覆盖率，您就可以决定是否值得继续重构以使代码更具可测试性。根据你的描述，我怀疑它会是。

score 0 · Accepted Answer

这些是我认为对单元测试有用的通用指南：

1) 识别边界对象（Win/WebForms、CustomControls 等）。

2）识别控制对象（业务层对象）

3) 只为边界对象调用的控制对象公共方法编写单元测试。这样您就可以确保您涵盖了应用程序的主要功能方面。

在您的情况下，如果业务规则与边界对象紧密耦合，您就会遇到麻烦 - 在我看来，您应该尝试根据应用程序的功能需求重构您的内容，重点关注热点。

这显然在很大程度上取决于具体情况。

score 0 · Accepted Answer

0

尝试开始阅读有关 TDD 的内容。

于 2009-11-25T12:24:09.707 回答

score 0 · Accepted Answer

0

您需要按原样测试您的代码，以确保在重构时不会破坏任何内容。

于 2010-10-13T07:48:48.173 回答

7 回答 7