我有一个项目,我正在尝试学习单元测试和TDD实践.我发现我遇到了一些令人困惑的案例,我花了很长时间为一个几乎无处不在的实用工具类设置模拟.
从我读到的关于单元测试的内容来看,如果我正在测试MyClass,我应该嘲笑任何其他功能(例如由UtilityClass提供).是否可以接受(假设UtilityClass本身有一套全面的测试)只使用UtilityClass而不是为所有不同的测试用例设置模拟?
编辑:我正在进行大量设置的事情之一.我正在建模地图,不同位置的不同对象.我的实用程序类的常用方法之一是GetDistanceBetween.我正在测试根据各自属性对事物产生影响的方法,例如,选择5个单位中的所有对象且年龄超过3的测试将需要多次测试(获取范围内的旧对象,忽略旧对象)范围,忽略范围内的年轻对象,每个案例的倍数正确工作)所有这些测试需要设置'GetDistanceBetween'方法.将每个使用GetDistanceBetween的方法(几乎每一个)与该方法在不同情况下应该返回的不同结果相乘,并且它会得到很多设置.
我可以看到,当我进一步开发时,可能会有更多实用程序类调用,大量对象以及这些模拟实用程序类上的大量设置.
Aar*_*lla 23
规则不是"模仿一切",而是"简化测试".如果,应该使用模拟
TDD并不是真正的测试.它的主要好处是帮助您设计干净,易于使用的代码,以便其他人理解和更改.如果它的主要好处是测试那么你就可以在代码之后而不是之前编写测试,并产生大部分相同的效果.
如果可以,我建议你不要把它们当作"单元测试".相反,请将您的测试视为如何使用代码的示例,以及其行为的描述,以说明您的代码有价值的原因.
作为该行为的一部分,您的类可能希望使用一些协作类.你可以嘲笑这些.
如果你的实用程序类是你的类行为的核心部分,并且你的类没有价值或没有它们的行为没有意义,那么不要嘲笑它们.
Aaron Digulla的答案非常好; 我根据这些原则重述了他的每一个答案:
协作类的行为很复杂,并且与您感兴趣的类的行为无关.
创建合作课程不是课堂上有价值的方面,也不需要成为课堂责任的一部分.
协作类提供了更改类的行为的上下文,因此将介绍如何使用它以及您可能期望的行为.
希望有道理!如果您喜欢它,请看看使用这种词汇的BDD远远超过"测试".
理论上,您应该尝试模拟所有依赖项,但实际上这是不可能的。例如,您不会模拟标准库中的基本类。在你的情况下,如果实用程序类只包含一些基本的辅助方法,我想我不会费心去模拟它。
如果它比这更复杂或者连接到一些外部资源,你必须模拟它。您可以考虑创建一个专用的模拟构建器类,它将创建一个标准模拟(定义了一些标准存根等),以便您可以避免在所有测试类中重复模拟代码。
| 归档时间: |
|
| 查看次数: |
2909 次 |
| 最近记录: |