你的测试越是类似于你的软件的使用方式,它们就越能给你带来信心。-我
人们在测试中面临的最大挑战之一是知道要测试什么。 这有很多原因,但有一个很大的、闪着光的原因是嘲弄。许多人不知道什么时候应该添加一个模拟版本的代码,或者让他们的测试直接运行实际的代码。这些都是我将在测试JavaScript课程的JavaScript嘲弄基础模块中帮助你解决的挑战。
**嘲弄可以让你以假乱真。**如果你不能拥有某些模块或服务的伪造版本,测试应用程序的结账过程将花费你大量的信用卡费用。说到为信心付出高昂的代价!所以,相反,我们做一个该信用卡收费服务的假版本来避免支付费用。
但是,嘲弄也是有代价的。
嘲弄切断了你正在测试的东西和你正在嘲弄的东西之间的真实世界的联系,即使我们有信心我们的代码能在假的信用卡服务版本中工作,我们也不能有100%的信心我们的代码会在生产中与真正的信用卡服务版本一起工作。
当你模拟一些东西时,你在做一个权衡,你在用信心换取其他东西。对我来说,这个东西通常是实用性--这意味着我根本无法测试这个东西,或者它可能非常困难/复杂,如果没有模拟。(就像我们的信用卡的例子)。
在我的UI单元和集成测试中,我有一个规则,我从不进行实际的网络调用;相反,我将通过模拟负责进行网络调用的模块来模拟服务器的响应。我也会模拟动画库,以避免在元素从页面中移除之前等待动画。除此以外,我的大部分UI测试都是使用真正的生产代码。对于E2E测试,我避免模拟任何东西(例如,除了后端打假或测试服务而不是实际的信用卡服务)。
每次测试节省几毫秒的时间?这不是一个嘲弄的好理由。人们喜欢浅层渲染--组件嘲弄到极致--因为它更快。 这是真的,但我们说的是几毫秒的速度。如果渲染整个组件树需要很长的时间,在我看来,你的软件有一个真正的性能问题需要解决。我意识到时间会增加(每个测试50ms*1000个测试=50秒)。但是,你模拟的越少,你需要的测试就越少,用信心来换取一两分钟的测试套件的速度是一个糟糕的交易。😵
嘲弄是有时间和地点的当你需要嘲弄时,Jest通过一些非常贴心的嘲弄工具使之变得简单。在testingjavascript.com中,我将向你展示如何在原始节点中实现Jest的一些嘲弄功能,这样你就可以了解到发生了什么。这很精彩。这里有一个在纯节点中模拟Jest的内联嘲弄功能的例子。
function fn(impl = () => {}) {
const mockFn = (...args) => {
mockFn.mock.calls.push(args)
return impl(...args)
}
mockFn.mock = {calls: []}
return mockFn
}
const utilsPath = require.resolve('~/utils')
require.cache[utilsPath] = {
id: utilsPath,
filename: utilsPath,
loaded: true,
exports: {
getWinner: fn((p1, p2) => p1),
},
}
现在,任何需要utils模块的代码都会得到该模块的mock函数版本。
这并不像Jest的内联嘲讽能力那样强大,但我们会在课程的JavaScript嘲讽基础模块中更多地讨论这个问题。