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

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

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

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

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

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

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

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

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

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

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

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

Damp =“描述性和有意义的短语”——你的单元测试应该能够被“读取”:

可读性比 避免冗余代码。

摘自文章:

DAMP代表“描述性和有意义的短语”，与DRY相反，并不是说“所有东西都应该看起来像垃圾堆，不可能阅读”，因为可读性比避免冗余代码更重要。 这意味着什么?在哪里使用它? DAMP主要应用于编写测试代码。测试代码应该非常容易理解，以至于某些冗余是可以接受的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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