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

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

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

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

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

可读性比 避免冗余代码。

摘自文章:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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