在讨论单元测试时，“DAMP not DRY”是什么意思？

Question

我听说有人说单位测试（例如nUnit，jUnit，xUnit）应该是

  

DAMP不是DRY

（例如，单元测试应包含“潮湿代码”而不是“干代码”）

他们在说什么？

Answer 1

这是一种平衡，而不是矛盾

DAMP和DRY并不矛盾，而是平衡了代码可维护性的两个不同方面。可维护的代码（易于更改的代码）是此处的最终目标。

DAMP （描述性和有意义的短语）提升了代码的可读性。

要维护代码，首先需要了解代码。要理解它，你必须阅读它。考虑一下你花了多少时间阅读代码。这是很多。 DAMP通过减少阅读和理解代码所需的时间来提高可维护性。

DRY （不要自己重复）宣传代码的 orthogonality 。

删除重复可确保系统中的每个概念在代码中都具有单个权威表示。对单个业务概念的更改会导致对代码的单个更改。 DRY通过将变更（风险）仅隔离到必须更改的系统部分来提高可维护性。

那么，为什么复制在测试中更容易被接受？

测试通常包含固有的重复，因为它们一遍又一遍地测试相同的东西，只是输入值或设置代码略有不同。但是，与生产代码不同，此复制通常仅与单个测试夹具/文件中的方案隔离。因此，重复是最小和明显的，这意味着它比其他类型的重复对项目造成的风险更小。

此外，删除此类重复会降低测试的可读性。之前在每个测试中重复的细节现在隐藏在一些新的方法或类中。为了全面了解测试，您现在必须将所有这些部分重新组合在一起。

因此，由于测试代码重复通常风险较小，并且提高了可读性，因此很容易看出它被认为是可接受的。

作为一个原则，在生产代码中支持DRY，在测试代码中支持DAMP。虽然两者同样重要，但只要有一点智慧，你就可以为自己提供平衡。

Answer 2

  

DAMP - 描述性和有意义的短语。

“DAMP not DRY”重视代码重用的可读性。在测试用例中DAMP不干的想法是测试应该易于理解，即使这意味着测试用例有时会重复代码。

另见Is duplicated code more tolerable in unit tests?关于这一观点的优点的讨论。

它可能是由Jay Fields创造的，与域特定语言有关。

Answer 3

“干”是“不要重复自己”

这个术语用于告诉人们编写可重用的代码，这样你就不会一遍又一遍地编写类似的代码。

“DAMP”是“描述性和有意义的短语”。

这个术语旨在告诉您编写可以被正在查看的人轻松理解的代码。如果您遵循这一原则，您将拥有长而描述性的变量和函数名称等。

Answer 4

Damp ='描述性和有意义的短语' - 您的单元测试应该能够“阅读”：

  

Readability is more important than avoiding redundant code.

来自文章：

  

DAMP代表“描述性和有意义的短语”，与DRY相反，不是因为它说“一切看起来像垃圾堆而且无法阅读”，因为可读性比避免冗余更重要代码。

     

这意味着什么以及在何处使用它？

  DAMP主要适用于编写测试代码。测试代码应该非常容易理解，以至于某些冗余是可以接受的。

Answer 5

DAMP代表“描述性和有意义的短语”，与DRY相反，不是因为它说“一切看起来像垃圾堆而且无法阅读”，因为可读性比避免冗余更重要代码。

http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/

Answer 6

这里有几个答案，但我想添加另一个，因为我认为他们不一定能够解释它。

DRY（不要重复自己）的想法是，在您的应用程序代码中，您希望避免冗余或重复代码。如果你的代码需要做多次，你应该有一个函数或类，而不是在几个地方重复类似的代码。

这是一个众所周知的编程概念。

DAMP（Descriptive and Meaninful Phrases）适用于您的单元测试。这里的想法是你的单元测试方法名称应该是长的和描述性的 - 有效的短句来描述你正在测试的内容。

例如：testWhenIAddOneAndOneIShouldGetTwo() { .... }

当您阅读这样的DAMP方法名称时，您应该准确理解测试编写者想要实现的目标，甚至不必阅读测试代码（尽管测试代码也可以遵循这个概念，当然还有罗嗦变量名等）。

这是可能的，因为单元测试方法具有非常特定的输入和预期输出，因此DAMP原理适用于它们。主应用程序代码中的方法不太具体，不足以保证这样的名称，特别是如果你在编写DRY原则的时候。

DAMP和DRY互不矛盾 - 它们涵盖了代码编写方式的不同方面 - 尽管如此，它们通常不会一起使用，因为用DRY原则编写的方法是通用的，不太可能适合高度具体的方法名称。因此，一般来说，如上所述，您的应用程序代码应为DRY，并且您的单元测试代码为DAMP。

我希望这有助于解释它。

Answer 7

我同意Chris Edwards的意见，你需要在两者之间取得平衡。另外需要注意的是，如果在尝试删除重复时，最终会在单元测试代码中添加大量额外结构（即将DRY置于极端时），则存在在其中引入错误的风险。在这种情况下，您要么必须对单元测试进行单元测试，要么保留未经测试的结构。

Answer 8

我不希望在这里复制这些工作，但你可以进行DAMP测试但是有DRY的好处。另一方面，在某些情况下，DRY测试不能满足DAMP测试。

I've blogged about DRY vs DAMP which includes some examples.

这两种方法都不是你唯一的解决方案，有时DAMP是过度杀伤，有时候是非常好的补充。

作为一般规则，您应该应用三条规则。如果你第三次发现重复，那么编写DAMP样式测试可能是值得的，但即便如此not all duplication is bad。背景很重要。