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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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