Question

我们现在开始使用UnitTests来提高我们的代码质量，并且（当然）出于其他原因。可悲的是，我们参加派对的时间已经很晚了，所以我们有大约50种方法的课程，这些课程到目前为止还没有经过考验。我们有很多课程！

是否可能/如何可能：
a）看哪些方法未经测试？
b）强制为类添加方法的开发人员为其编写单元测试（例如，我实现测试所有50种方法，明天有人添加51.方法）？
c）当方法未经测试时发出警告或错误？

Answer 1

a）查看哪些方法未经测试？

使用Code Coverage工具相当容易。 Visual Studio中内置了一个，但也有其他选项。

b）强制为类添加方法的开发人员为其编写单元测试（例如，我实现测试所有50个方法，明天有人添加51.方法）？

不要根据承保范围制定严格的规则！

所有经验（包括我的）都表明，如果您设置了硬编码覆盖目标，那么您获得的唯一结果就是开发人员将开始游戏系统。结果将是更糟糕的代码。

这是一个例子;考虑这个Reverse方法：

public static string Reverse(string s)
{
    char[] charArray = s.ToCharArray();
    Array.Reverse(charArray);
    return new string(charArray);
}

您可以编写单个测试以获得此方法的100％覆盖率。但是，正如这里给出的那样，实现很脆弱：如果s是null会发生什么？该方法将抛出NullReferenceException。

更好的实现方法是检查s null，并添加一个处理该情况的分支，但除非您为其编写测试，否则代码覆盖率将会下降。

如果您的开发人员不想编写测试，但您需要一个硬代码覆盖目标，那么此类开发人员将按原样保留Reverse函数，而不是改进它。

我在野外看过这样的系统游戏。如果您制定了一条没有买方支持的规则，就会发生。

如果他们添加了良好的单元测试，你需要教会开发人员如何使他们的工作变得更容易。

一旦开发人员理解了这一点，他们就会自己添加测试，而且你不需要任何规则。

只要开发人员不理解这一点，该规则只会对您造成更大的伤害，因为您将从中获得的“测试”不会理解。

c）在方法未经测试时发出警告或错误？

如上所述，如果用于绝对指标，代码覆盖率是一个糟糕的工具。另一方面，如果您开始监控趋势，它会非常有用。

一般来说，代码覆盖率应该会增加，直到达到某个高原，而增加代码覆盖率是不切实际的。

有时，它甚至可能会下降，这可能是好的，只要有充分的理由。监控覆盖率趋势会告诉您覆盖范围何时下降，然后您可以进行调查。有时候，有一个很好的理由（例如当有人添加Humble Object时），但有时却没有，并且您需要与负责删除的开发人员交谈。

Answer 2

要查看未经测试的方法，可以使用代码覆盖工具（内置或外部工具，如NCrunch，dotCover）。这取决于您的需求，根据结果格式，报告等。

这些工具既可以使用VS也可以运行，例如使用构建服务器构建时（如TeamCity，Bamboo）。当代码覆盖率降低（以某种方式回答你的c）问题时，可以将构建设置为失败）。

在我看来，你应该强迫dev通过一些插件来编写单元测试。它应该是您的过程的一部分，可以在代码审查期间指出。更重要的是 - 您想知道何时强制编写测试？我的意思是 - 你不知道开发过程什么时候结束，所以很难告诉某人＆＃34;写你的测试知道＆＃34;。

编辑：如果你想要TC的免费代码覆盖工具，我知道的是OpenCover - 你可以很容易地找到有关插件安装和使用的一些信息。

Answer 3

这很有趣，你的B部分“强迫开发人员添加..”是我几分钟前发布的一个问题，我得到了很多投票，我删除了这个问题，因为显然，这不是正确的方法强迫别人写测试，它应该是你在组织中设置的“文化”。

所以对你的问题（这有点宽，但仍然可以得到一些方向）：

一个。您可以使用现有的代码覆盖工具/库或实现自己的代码覆盖工具/库来实现此功能，这是一个很好的帖子，其中提到了一些。 What can I use for good quality Code Coverage for C#/.NET?

您可以根据此类库建立自定义，以帮助实现对c部分的回答（在未经测试的情况下发出警告或错误）。

b。如果可以，你应该尝试实施TDD，并在编写方法之前编写测试，这样你就不必强迫任何东西了。如果由于时间和资源方面的考虑而无法更改方法，则无法执行此操作，请执行TED（测试最终开发）。

是的，它不是单元测试，但你仍然会有一个有价值的测试。