jest.fn()要解决的问题范围是什么?

mocks和stubs要解决的问题是,您通常不想 真叫 测试中的某些方法或依赖项,因为:

• 它们不可靠,如HTTP请求:

  如果您有一个模块,而不是显示从Internet上获取的用户列表,则在测试模块时,您不希望测试因网络连接不良、缺少凭据等而失败。

• 它们很难在您的测试中设置:

  一些模块或依赖项需要大量的参数/设置条件,以便被测试的模块能够使用,从而使测试变得困难和容易出错。通过模拟或删除这种依赖关系,您可以测试 被测模块的逻辑 无需处理管理依赖性需求的负担。

• 他们有自己的测试:

  如果您正在测试一个依赖i18n模块的传送带模块,并且您还测试过i18n模块,则不希望测试它是否正常工作。 再一次 . 您模拟了它,所以您可以自由地使用i18n模块设置和依赖项。

• 它们的计算强度很高:

  假设你想测试一个反应/角度/Vue…用于显示Web视频游戏的UI仪表板和菜单的组件。在测试游戏仪表板的导航栏是否按预期运行时,您绝对不希望实际运行游戏。

因此,在测试时,您最终会模拟并删除许多依赖项,它们应该是执行HTTP调用的函数,或者是结构模块(如Flux Store或i18n插件)。

jest.fn() 尤其是在功能层面上。例如,您正在测试的Vue组件 created() hook调用一些方法来执行您在测试中不想处理的事情:

可能它调用了一个API,扰乱了本地存储,或者做了一些计算量很大的事情。所以你监视这个方法放置 笑话(Fn) 在它的位置上,你只是断言 它应该在什么时候被召唤 .