谈到unit testing时，“DAMP不干”是什么意思？
我听到有人说unit testing（例如nUnit，jUnit，xUnit）应该是
DAMP 不干
（例如unit testing应该包含“湿码”而不是“干码”）
他们在说什么？
这是一个平衡，而不是矛盾
DAMP和DRY并不矛盾，而是平衡了代码可维护性的两个不同方面。 可维护的代码（易于更改的代码）是这里的最终目标。
DAMP （描述性和有意义的短语）促进了代码的可读性 。
要维护代码，首先需要了解代码。 要理解它，你必须阅读它。 考虑一下你花了多less时间阅读代码。 这很多。 DAMP通过减less阅读和理解代码所需的时间来提高可维护性。
干 （不要重复自己）促进代码的正交性。
删除重复确保系统中的每个概念在代码中都有一个权威的表示。 对单一业务概念的更改会导致对代码进行单一更改。 DRY通过将变化（风险）仅隔离到必须改变的系统的那些部分来增加可维护性。
那么，为什么重复testing更容易被接受呢？
testing通常包含固有的重复，因为他们一遍又一遍地testing相同的东西，只是input值或设置代码略有不同。 但是，与生产代码不同，这种重复通常只能隔离到单个testing夹具/文件中的情况。 正因为如此，重复是微不足道的，明显的，这意味着它比其他types的重复项目风险较低。
而且，消除这种重复会降低testing的可读性。 以前在每个testing中重复的细节现在隐藏在一些新的方法或类中。 为了全面了解这个testing，你现在必须把所有这些东西重新整合起来。
因此，由于testing代码重复通常风险较小，且可读性较高，因此很容易看出它是如何被认为是可以接受的。
作为原则，在生产代码中支持DRY，在testing代码中使用DAMP。 虽然两者都同样重要，但有一点智慧，可以平衡你的利益。
DAMP – 描述性和有意义的短语。
“DAMP不干”值重读代码重用。 在testing用例中，DAMP不干的想法是testing应该易于理解，即使这意味着testing用例有时会有重复的代码。
另请参阅unit testing中的重复代码更容易？ 对这个观点的优点进行一些讨论。
它可能是由Jay Fields创build的 ，涉及领域特定语言。
“干”是“不要重复自己”
这是一个用来告诉人们编写可重复使用的代码的术语，所以你最终不会一次又一次地写出类似的代码。
“DAMP”是“描述性和有意义的短语”。
这个术语的目的是告诉你写一些代码，这个代码很容易被正在看的人理解。 如果你遵循这个原则，你将有很长的描述性variables和函数名称等等。
潮湿='描述性和有意义的短语' – 你的unit testing应该能够'读'：
可读性比避免冗余代码更重要。
DAMP代表“描述性的和有意义的短语”，与DRY相反，不是说“所有东西都应该看起来像垃圾堆，不可能读”，因为可读性比避免冗余代码更重要。
这里已经有几个答案了，但我想补充一个，因为我不认为他们必须尽可能好地解释它。
DRY（不要重复自己）的想法是在你的应用程序代码中你想避免冗余或重复的代码。 如果你的代码需要多次执行，你应该有一个函数或类，而不是在几个地方重复类似的代码。
这是一个相当知名的编程概念。
DAMP（描述性和意思性的短语）适用于你的unit testing。 这里的想法是，你的unit testing方法名称应该是长和描述性的 – 有效地简短描述你正在testing的句子。
例如： testWhenIAddOneAndOneIShouldGetTwo() { .... }
当你读到这样一个DAMP方法名时，你应该准确地理解testing编写者试图达到什么目的，甚至不需要阅读testing代码（虽然testing代码也可以遵循这个概念，当然还有罗嗦的variables名，等等）。
这是可能的，因为unit testing方法具有非常具体的input和期望的输出，所以DAMP原理适用于他们。 主要应用程序代码中的方法不太可能具有足够的特性来保证这样的名称，特别是如果您已经根据DRY原则编写它的话。
DAMP和DRY不会相互矛盾 – 它们涵盖了代码编写的不同方面 – 但是它们通常并不是一起使用，因为记住DRY原则的方法是通用的，不太适合以非常具体的方法名称。 因此，一般来说，如上所述，您的应用程序代码应该是DRY和您的unit testing代码DAMP。
我希望这有助于解释一点。
我同意克里斯·爱德华兹的观点，你需要在两者之间取得平衡。 另外需要注意的是，如果为了消除重复，最后在unit testing代码中增加了很多额外的结构（例如，当干到极限时），就会冒着在那里引入错误的风险。 在这种情况下，你可能要么unit testing你的unit testing，要么留下一些未经testing的结构。
我不想在这里重复这个工作，但是你可以进行DAMPtesting但是有DRY的好处。 另一方面，在某些情况下，DRYtesting不能满足DAMPtesting。
我已经写了关于DRY和DAMP的一些例子。
这两种方法都不应该是你唯一的解决scheme，有时候DAMP是过度杀伤的，有时候是一个很好的补充。
一般来说，你应该运用三条规则。 如果你第三次发现重复，可能需要考虑编写DAMP风格的testing，但即使如此， 并非所有的重复都是不好的 。 情境很重要。
