我听到有人说单元测试(例如nUnit, jUnit, xUnit)应该是
潮湿而不干燥
(例如,单元测试应该包含“潮湿代码”而不是“干代码”)
他们在谈论什么?
我听到有人说单元测试(例如nUnit, jUnit, xUnit)应该是
潮湿而不干燥
(例如,单元测试应该包含“潮湿代码”而不是“干代码”)
他们在谈论什么?
当前回答
DAMP -描述性和有意义的短语。
“DAMP not DRY”重视代码重用的可读性。测试用例中的“潮湿而不是干燥”的思想是,测试应该易于理解,即使这意味着测试用例有时有重复的代码。
参见单元测试中重复代码是否更可容忍?对于这一观点的优点进行了一些讨论。
它可能是由Jay Fields创造的,与领域特定语言有关。
其他回答
我同意Chris Edwards的观点,你需要在两者之间取得平衡。另一件需要注意的事情是,如果为了消除重复,你最终会在你的单元测试代码中添加很多额外的结构(例如,当DRY走向极端时),你会冒着在那里引入错误的风险。在这种情况下,您要么必须对单元测试进行单元测试,要么保留部分结构未测试。
DAMP代表“描述性和有意义的短语”,与DRY相反,并不是说“所有东西都应该看起来像垃圾堆,不可能阅读”,因为可读性比避免冗余代码更重要。
http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/
“DRY”是“不要重复你自己”
这是一个用来告诉人们编写可重用代码的术语,这样你就不会一遍又一遍地编写类似的代码。
“DAMP”是“描述性和有意义的短语”。
这个术语的目的是告诉你编写的代码要能被看代码的人很容易理解。如果你遵循这个原则,你就会有很长的描述性变量和函数名等等。
DAMP -描述性和有意义的短语。
“DAMP not DRY”重视代码重用的可读性。测试用例中的“潮湿而不是干燥”的思想是,测试应该易于理解,即使这意味着测试用例有时有重复的代码。
参见单元测试中重复代码是否更可容忍?对于这一观点的优点进行了一些讨论。
它可能是由Jay Fields创造的,与领域特定语言有关。
我不希望在这里重复这种工作,但是您可以拥有具有DRY好处的DAMP测试。另一方面,在某些情况下,DRY测试不能满足DAMP测试。
我曾经在博客上写过DRY vs DAMP的例子。
这两种方法都不应该是你唯一的解决方案,有时DAMP是多余的,其他时候是非常好的补充。
一般来说,你应该运用“三原则”。如果第三次发现重复,可能值得考虑编写DAMP风格测试,但即使这样,也不是所有的重复都不好。环境很重要。