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

可读性比 避免冗余代码。

摘自文章:

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

这里已经有几个答案了，但我想补充一个，因为我认为他们不一定能解释得很好。

DRY(不要重复你自己)的思想是在你的应用程序代码中，你要避免冗余或重复的代码。如果你有一些代码需要多次执行的事情，你应该为它提供一个函数或类，而不是在几个地方重复类似的代码。

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

DAMP(描述性和有意义的短语)是用于单元测试的。这里的想法是您的单元测试方法名称应该长且具有描述性——有效地用短句描述您正在测试的内容。

例如:testWhenIAddOneAndOneIShouldGetTwo() {....｝

当您阅读像这样的DAMP方法名称时，您应该确切地理解测试编写人员试图实现什么，甚至不需要阅读测试代码(尽管测试代码也可以遵循这个概念，当然有啰嗦的变量名等)。

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

DAMP和DRY并不相互矛盾——它们涵盖了代码编写方式的不同方面——但尽管如此，它们通常不会一起使用，因为按照DRY原则编写的方法是通用的，不太可能适合高度特定的方法名称。因此，正如上面所解释的，一般来说，应用程序代码应该是DRY的，而单元测试代码应该是DAMP的。

我希望这有助于更好地解释它。

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

可读性比 避免冗余代码。

摘自文章:

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

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

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

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

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

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

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

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

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

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

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

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

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