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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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的。

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