模拟或真正的课程?

and*_*ykx 12 unit-testing mocking

使用其他类(作为成员或作为方法的参数)的类需要具有适合单元测试的实例.如果你有这些类可用并且没有引入其他依赖项,那么使用真实的东西而不是模拟更好吗?

Mik*_*eck 16

我说尽可能使用真正的课程.

我非常相信尽可能扩大"单元"测试的界限.在这一点上,它们不是传统意义上的单元测试,而只是一个适用于您的应用程序的自动回归套件.我仍然练习TDD并首先编写我的所有测试,但是我的测试比大多数人的测试要大一些,而我的绿 - 红 - 绿周期需要更长的时间.但是现在我已经这样做了一段时间,我完全相信传统意义上的单元测试并不是他们所能完成的.

根据我的经验,编写一些小的单元测试最终会成为未来重构的障碍.如果我有一个使用B的A类,我通过模拟B对其进行单元测试,当我决定将某些功能从A移动到B或反之亦然时,我的所有测试和模拟都必须改变.现在,如果我有测试验证通过系统的端到端流程按预期工作,那么我的测试实际上帮助我确定我的重构可能导致系统外部行为发生变化的地方.

底线是模拟编码特定类的合同,并且最终实际上也指定了一些实现细节.如果您在整个测试套件中广泛使用模拟,那么您的代码库最终将会产生许多额外的惯性,从而抵制任何未来的重构工作.

  • "我喜欢,但我知道这不是最好的方法." 根据谁?在某种程度上,这取决于你的目标是什么.如果你正在尝试编写一个非常小的测试来隔离一个特定的方法,这样你可以围绕实现那个单元的最佳方式,那么模拟是有帮助的,但如果你试图建立一个将编纂的回归套件你的系统的行为,并在它意外改变时提醒你,我的经验是,大量的模拟使用绝对不是最好的方法. (3认同)
  • 我也喜欢这样的方法,但是 1. 那不是 UNIT 测试,但看起来像 INTEGRATION 测试;2. 我喜欢,但我明白这不是最好的方法。 (2认同)

Ste*_*e g 5

只要您对对象有绝对的控制权,就可以使用“真实的东西”。例如,如果你有一个只有属性和访问器的对象,你可能没问题。如果要使用的对象中有逻辑,则可能会遇到问题。

如果类 a 的单元测试使用类 b 的实例并且引入 b 的更改破坏了 b,则类 a 的测试也被破坏。这是您可能遇到问题的地方,就像使用模拟对象一样,您始终可以返回正确的值。使用“真实的东西”可以使测试变得复杂并隐藏真正的问题。

模拟也有缺点,我认为在一些模拟和一些你必须自己找到的真实对象之间存在平衡。


Spo*_*ike 5

你想使用存根/模拟而不是真正的类有一个很好的理由。即使您的单元测试(纯单元测试)类在测试与其他所有内容隔离。这个属性非常有用,保持测试隔离的好处很多:

  • 测试运行得更快,因为它们不需要调用真正的类实现。如果实现是针对文件系统或关系数据库运行,那么测试将变得缓慢。缓慢的测试使开发人员不会经常运行单元测试。如果您在进行测试驱动开发,那么占用大量时间的测试一起是对开发人员时间的毁灭性浪费。
  • 如果测试与被测类隔离,则更容易追踪问题。与系统测试相比,追踪在堆栈跟踪中不明显可见的讨厌的错误要困难得多。
  • 测试对外部类/接口所做的更改不那么脆弱,因为您纯粹是在测试被测类。低脆弱性也是低耦合的标志,这是一个很好的软件工程。
  • 您正在测试类的外部行为,而不是内部实现,这在决定代码设计时更有用。

现在,如果您想在测试中使用真正的类,那很好,但它不是单元测试。您正在执行集成测试,这对于验证需求和整体健全性检查很有用。集成测试不像单元测试那样经常运行,实际上它主要在提交到最喜欢的代码存储库之前完成,但同样重要。

您唯一需要记住的是以下几点:

  • 模拟和存根用于单元测试。

  • 真正的类用于集成/系统测试。