单元测试 – 使用“真实”实用程序类而不是在TDD中嘲笑是可以接受的吗?

我有一个项目,我正在尝试学习单元测试和TDD实践.我发现我正在花费很长时间来设计一个几乎在所有地方使用的实用程序类的嘲笑案例.

从我读过的关于单元测试的信息,如果我正在测试MyClass,我应该嘲笑任何其他功能(如由UtilityClass提供).是否可以接受(假设UtilityClass本身有一套全面的测试)来使用UtilityClass而不是为所有不同的测试用例设置mock?

编辑:我正在做很多设置之一.
我正在对地图进行建模,在不同的位置使用不同的对象.我的实用工具类的常见方法之一是GetdistanceBetween.我正在测试根据其各自属性对事物产生影响的方法,例如,选择一个点的5个单位内的所有对象和3岁以上的年龄的测试将需要进行几次测试(获取范围内的旧对象,忽略旧对象的范围,忽略范围内的年轻物体,正确与每种情况的倍数),所有这些测试需要设置“GetdistanceBetween”方法.通过使用GetdistanceBetween(几乎每一个)的方法和不同的结果,该方法应该在不同的情况下返回,并且它将被做很多设置.

我可以看到,当我进一步开发,可能会有更多的实用程序类调用,大量的对象和很多设置在这些模拟实用程序类.

规则不是“模拟一切”,而是“使测试简单”.应该使用嘲讽

>您无法以合理的努力创建一个实例(请参阅:您需要单个方法调用,但是创建实例,则需要一个工作数据库,一个DB连接和另外5个类).>创建额外的课程是昂贵的.>其他类返回不稳定值(如当前时间或数据库中的主键)

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...