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

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

参见单元测试中重复代码是否更可容忍?对于这一观点的优点进行了一些讨论。

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

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

我曾经在博客上写过DRY vs DAMP的例子。

这两种方法都不应该是你唯一的解决方案，有时DAMP是多余的，其他时候是非常好的补充。

一般来说，你应该运用“三原则”。如果第三次发现重复，可能值得考虑编写DAMP风格测试，但即使这样，也不是所有的重复都不好。环境很重要。

“DRY”是“不要重复你自己”

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

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

这个术语的目的是告诉你编写的代码要能被看代码的人很容易理解。如果你遵循这个原则，你就会有很长的描述性变量和函数名等等。

DAMP代表“描述性和有意义的短语”，与DRY相反，并不是说“所有东西都应该看起来像垃圾堆，不可能阅读”，因为可读性比避免冗余代码更重要。

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

我同意Chris Edwards的观点，你需要在两者之间取得平衡。另一件需要注意的事情是，如果为了消除重复，你最终会在你的单元测试代码中添加很多额外的结构(例如，当DRY走向极端时)，你会冒着在那里引入错误的风险。在这种情况下，您要么必须对单元测试进行单元测试，要么保留部分结构未测试。

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

DAMP和DRY并不矛盾，相反，它们平衡了代码可维护性的两个不同方面。可维护的代码(易于更改的代码)是这里的最终目标。

DAMP(描述性和有意义的短语)提高了代码的可读性。

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

DRY(不要重复你自己)提倡代码的正交性。

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

那么，为什么重复在测试中更容易被接受呢?

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

此外，删除这种重复降低了测试的可读性。以前在每个测试中重复的细节现在隐藏在一些新的方法或类中。为了获得测试的全貌，您现在必须在心里将所有这些片段重新组合在一起。

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

作为一个原则，在生产代码中支持DRY，在测试代码中支持DAMP。虽然这两者同样重要，但只要你有一点智慧，你就能打破平衡。