我听说有人说单元测试(例如nUnit,jUnit,xUnit)应该是
(例如,单元测试应该包含"潮湿代码"而不是"干代码")
他们在说什么？
小智 537
DAMP和DRY并不矛盾,而是它们平衡了代码可维护性的两个不同方面.可维护的代码(易于更改的代码)是此处的最终目标.
要维护代码,首先需要了解代码.要理解它,你必须阅读它.考虑一下您花多少时间阅读代码.这是很多. DAMP通过减少读取和理解代码所需的时间来提高可维护性.
删除重复可确保系统中的每个概念在代码中都具有单个权威表示.对单个业务概念的更改会导致对代码的单个更改.DRY通过将变更(风险)仅隔离到必须更改的系统部分来提高可维护性.
测试通常包含固有的重复,因为它们反复测试相同的东西,只是输入值或设置代码稍有不同.但是,与生产代码不同,此复制通常仅与单个测试夹具/文件中的方案隔离.因此,重复是最小和明显的,这意味着它比其他类型的重复对项目造成的风险更小.
此外,删除这种重复会降低测试的可读性.之前在每个测试中重复的细节现在隐藏在一些新的方法或类中.为了全面了解测试结果,您现在必须将所有这些部件重新组合在一起.
因此,由于测试代码重复通常风险较小,并且提高了可读性,因此很容易看出它被认为是可接受的.
作为一个原则,在生产代码中支持DRY,在测试代码中支持DAMP.虽然两者同样重要,但只要有一点点智慧,你就可以为自己提供平衡.
Dom*_*ger 59
DAMP - 描述性和有意义的短语.
"DAMP not DRY"重视代码重用的可读性.在测试用例中DAMP不干的想法是测试应该易于理解,即使这意味着测试用例有时会重复代码.
另请参阅单元测试中是否可以容忍重复代码？关于这一观点的优点的一些讨论.
它可能是由Jay Fields创建的,与Domain Specific Languages相关.
Spu*_*ley 29
"干"是"不要重复自己"
这个术语用于告诉人们编写可重用的代码,这样您就不会一遍又一遍地编写类似的代码.
"DAMP"是"描述性和有意义的短语".
这个术语旨在告诉您编写代码,这些代码可以让正在查看它的人轻松理解.如果您遵循这一原则,您将拥有长而描述性的变量和函数名称等.
stu*_*rtd 20
潮湿='描述性和有意义的短语' - 您的单元测试应该能够"读取":
来自文章:
DAMP代表"描述性和有意义的短语",与DRY相反,不是说"一切看起来像垃圾堆而且无法读取",因为可读性比避免冗余代码更重要.
这意味着什么以及在哪里使用它？
DAMP主要适用于编写测试代码.测试代码应该非常容易理解,以至于某些冗余是可以接受的.
SDC*_*SDC 11
这里有几个答案,但我想添加另一个,因为我认为他们不一定能够解释它.
DRY(不要重复自己)的想法是,在您的应用程序代码中,您希望避免冗余或重新编写代码.如果你的代码需要做多次,你应该有一个函数或类,而不是在几个地方重复类似的代码.
这是一个众所周知的编程概念.
DAMP(Descriptive and Meaninful Phrases)适用于您的单元测试.这里的想法是你的单元测试方法名称应该是长的和描述性的 - 有效的短句来描述你正在测试的东西.
例如: testWhenIAddOneAndOneIShouldGetTwo() { .... }
当您阅读这样的DAMP方法名称时,您应该准确理解测试编写者试图实现的内容,甚至不必阅读测试代码(尽管测试代码也可以遵循这个概念,当然还有罗嗦的变量名称,等等).
这是可能的,因为单元测试方法具有非常特定的输入和预期输出,因此DAMP原理适用于它们.主应用程序代码中的方法不太具体,不足以保证这样的名称,特别是如果您在编写DRY原则时.
DAMP和DRY并不相互矛盾 - 它们涵盖了代码编写方式的不同方面 - 但是它们通常不会一起使用,因为用DRY原则编写的方法是通用的,不太适合高度具体的方法名称.因此,一般情况下,如上所述,您的应用程序代码应为DRY,并且您的单元测试代码为DAMP.
我希望这有助于解释它更好一点.
我同意Chris Edwards的意见,你需要在两者之间取得平衡.另一件需要注意的事情是,如果在尝试删除重复时,最终会在单元测试代码中添加大量额外结构(即将DRY置于极端情况下),则存在在其中引入错误的风险.在这种情况下,您要么必须对单元测试进行单元测试,要么保留未经测试的结构.
| 归档时间： |
|
| 查看次数： |
58659 次 |
| 最近记录： |