共计 2832 个字符，预计需要花费 8 分钟才能阅读完成。
前言
哈喽，大家好，我是海怪。
在做前端测试时，选用适合的测试策略远比一通猛狂测试更重要，所谓 “方向 > 致力”。
如果抉择了谬误的测试策略，很容易写出维护性差和不稳固的测试用例。一旦业务呈现变动，用例就全崩了。可能这也是大家厌恶写测试的起因之一吧。
Kent C. Dodds 在这篇文章 [《Common Testing Mistakes
》](https://kentcdodds.com/blog/c… “《Common Testing Mistakes》”) 分享 了 3 个他看到的测试误区。明天，就把这篇文章分享给大家吧~
翻译中会尽量用更纯粹的语言，这也意味着会给原文加一层 Buf，想看原文的可点击 这里。
正片开始
误区一：测试代码的实现细节
说实话，我十分喜爱这个误区（详情能够看这里），因为在测试过程中，它是一个很重大的问题，这样写测试也不会带给你对应的信念。上面是一个测试代码实现细节的例子：
// counter.js
import * as React from 'react'
export class Counter extends React.Component {state = {count: 0}
increment = () => this.setState(({count}) => ({count: count + 1}))
render() {const {count} = this.state
return <button onClick={this.increment}>{count}</button>
}
}
// __tests__/counter.js
import * as React from 'react'
// 用 React Testing Library 是很难测代码实现细节的，所以这里用 enzyme 来测
import {mount} from 'enzyme'
import {Counter} from '../counter'
test('the increment method increments count', () => {const wrapper = mount(<Counter />)
// 千万别这么做
expect(wrapper.instance().state.count).toBe(0)
wrapper.instance().increment()
expect(wrapper.instance().state.count).toBe(1)
})为什么说下面是在测代码实现细节？以及，为什么测代码细节是不好的呢？像下面那样适度测试实现细节会带来两个后果：
- 我能够在测试齐全通过的状况下弄崩业务代码 （比方在
onClick赋值时成心写错变量名） - 我能够在重构业务代码的时候弄崩测试用例 （例如，把
increment重命名为updateCount，测试就崩了，但业务代码是能失常运行的）
（译注：作者对重构的了解是：改变业务代码逻辑时，测试代码不应该做改变的， 因为业务逻辑没变，只是实现形式变了 ）
相似这样的测试用例是最难保护的，因为你要一直地更新它们（基于下面第二点），同时，它们也不会给你带来更多代码的信念（基于下面第一点）。
误区二：100% 代码覆盖率
另一个误区就是强求 100% 的代码覆盖率。 乏味的是，我常常看到在一些我的项目里会被强制要求 100% 的覆盖率。不论这种规定是从哪来的，这其实都是对代码笼罩的误会，因为这样并不能给你带来相与之对应的代码信念。
代码笼罩只能通知你一件事：
- 这行代码有被测试用例跑过
然而，它没有通知你的事有：
- 代码是否按业务需要来失常工作
- 代码是否能和我的项目里其它代码一起工作
- 我的项目崩了的时候会产生什么（这里指意外解体）
代码覆盖率的另一个问题是：每减少一行代码的笼罩，整体笼罩量也会被减少。也就是说，如果你想进步整体覆盖率，那么在“领取页”增加测试和在“对于”页增加测试的成果是一样的（整体覆盖率变高了）。比这更重大的另一个问题是： 这样的覆盖率不能让你深刻地理解你的我的项目 …
目前来说，还没有一种万能的解决方案来取得精确的代码覆盖率，毕竟每个我的项目的需要是不同的。我个别不会适度关注代码覆盖率，而是更关注于我的项目里重要的局部是否笼罩到位。在确定我的项目中的要害局部之后，我会利用覆盖率报告来找出还未被测试笼罩到的边界状况。
申明一下，对于开源模块来说，100% 代码覆盖率是齐全正当的，因为它们个别更容易达到 100% 覆盖率（我的项目不大，而且绝对简略），而且他们都是很重要的代码，会被很多别的我的项目援用。
误区三：反复测试
相比于集成测试和单测，大多数人吐槽 E2E 最多就是很慢和不牢靠。 你是不可能让单个 E2E 测试既能跑得快，又能像单测那样稳固的。反正就是不可能的。不过话说回来，单个 E2E 测试会比单测带来更多代码信念。在很多状况下，单测是不能像 E2E 那样带来那么高的代码信念的，所以我的项目中写点 E2E 测试是必定值回本的！
当然，下面这么说不代表咱们不能让咱们的 E2E 测试跑更快和变得更牢靠。其中，反复测试是人们写 E2E 测试时常常踩的一个坑，这会让升高整个测试的性能以及可靠性。
咱们应该要在隔离环境下执行测试。实践上，每个独自的 E2E 测试在执行时都应该像不同的用户应用软件一样。这样的话，每次跑测试都要走一遍注册登录流程来创立新用户了，对吧？看起来如同是对的，而后你每次就要点点按钮，输出用户信息来做注册登录。这么做只是为了业务中要用一下用户的登录态，是吧？错！这是不对的！
让咱们回过头来想：为什么要写测试？因为这样你能够交付出更有自信、不容易解体的我的项目呀！如果，你有 100 个测试须要用已登录的用户来执行。那你应该要跑多少次注册 / 登录流程来让你置信代码是没问题呢？100 次还是 1 次？正常人都会选 1 次，因为只有 1 次胜利，处处都应该胜利。因而，剩下的 99 次额定的测试并不会给你带来任何代码信念。 它们只是在做无用功。
那你应该怎么做呢？既然咱们曾经搭建好了测试的隔离环境，那么就不应该在测试之间共享同一个 user。 我举荐的做法是：当每次要注册和登录新用户时，在我的项目中发送同一个 HTTP 申请！发送申请必定比在页面点击选中输入框和输出用户名、明码来得更快，而且会产生更少的假谬误 （译注：假谬误是指：测试失败了，然而其实利用代码自身没任何问题）。只有你能保障有 1 个能残缺跑通注册 / 登录的流程，那么你就不会失去这个登录注册流程的信念。
总结
肯定要时刻记住咱们写测试是为了进步代码信念。如果你当初做的事不能让你进步对代码的信念，那能够思考你是否真的要这么做！
好了，这篇外文就给大家带到这里了。这篇文章次要列举了 3 个误区：防止适度测试代码细节、防止 100% 笼罩以及防止反复测试。这三个误区的产生都是因为咱们没有搞清楚测试的实质：进步代码自信。当你很苦楚地编写测试用例的时候，那么很可能你钻入了牛角尖，往谬误的方向写测试了，这时就要进行而后回过头来想：怎么做能力进步代码自信呢？
如果你喜爱我的分享，能够来一波一键三连，点赞、在看就是我最大的能源，比心 ❤️
