单元测试的代码质量？

Question

在编写单元测试时，是否值得花费额外的时间来使代码具有良好的质量和可读性？

在编写测试时，为了更快地编写和避免使用如此多的变量，我经常破坏德米特定律。从技术上讲，单元测试并不是直接重用的--它们严格地绑定到代码中，所以我不认为有什么理由花太多时间在它们上；它们只需要是功能性的。

Answer 1

在质量和可读性方面，您肯定应该在质量和可读性方面比产品代码更好地处理单元测试。单元测试通常是当您试图掌握某段代码所做的事情时首先看到的东西，而读者在查看测试时应该迅速了解所涉及的问题。单元测试也往往会发生很大的变化，如果它们的设计不健壮，就会破坏很多，这就抵消了测试的好处。

由于这个原因，在单元测试中违反Demeter定律绝对是一个问题，我还想到了另外两个问题：

• 如果您的测试在其安排或行动部分中违反了Demeter定律，这可能是一个迹象，表明您的生产代码也是如此，因为您的单元测试只是代码的另一个使用者，并且可能会以与其他任何生产代码相同的方式调用和操作被测试的类。
• 如果您的测试在断言部分(即验证在被测试对象的依赖关系图中深深嵌套的东西的值)中违反了Demeter定律，那么这些可能是真正的集成测试，而不是单元测试。换句话说，如果你在TestA中断言A.B.C.D等于某种东西，那么你可能实际上是在测试D和A，而不仅仅是A。

顺便说一下，当你说

我经常打破德米特定律，为了更快的写作而不是使用这么多的变量。

你应该意识到

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

实际上，德米特的智慧并没有比

myDependency.Grab.Something.Very.Deep();

如果你是这个意思的话。

Answer 2

绝对值得花时间为单元测试编写高质量的代码：

• 它们和其他代码一样需要维护。
• 单元测试是系统文档的最佳来源之一，也可以说是最可靠的形式。他们真的应该展示：
  • 意图：“预期的行为是什么？”
  • 用法：“我应该如何使用这个API?”

• 与任何其他代码一样，它们需要调试。

支持稍微特别的方法的一个因素是，您的单元测试永远不会是公共API，因此您不需要担心暴露了哪些接口/等等。

Answer 3

是的，这很重要。单元测试应该保持与其他代码相同的标准，原因有几个：

• 每个单元测试也用作测试的文档。当测试是全面的，涵盖尽可能多的边缘情况和错误条件时，它们通常可以替换类或函数的注释文档。它们也可以作为代码基础新手的起点。
• 单元测试也可能是错误的。当代码编写得很好时，错误就更加明显了。
• 如果由于某种原因，以后需要拆分一个模块，那么您可能也需要拆分它的单元测试。如果编写的测试具有易于识别的依赖关系，这就更容易了。

尽管如此，始终存在着实用性的问题。根据代码的语言和性质，如果不花费更多的时间在测试上而不是应该测试的代码上，就很难编写“干净”的单元测试。在这种情况下，我通常会回到测试简单、快速的东西和最关键的功能上，而不用担心完全覆盖。每当稍后出现错误时，我都会为它编写一个测试，并检查是否可以重构新的测试和现有的测试，以使它们更好。