前言
在做前端测试时，选用合适的测试策略远比一通狂写测试更重要，所谓 “方向 > 努力”。
如果选择了错误的测试策略，很容易写出维护性差和不稳定的测试用例。一旦业务出现变化，用例就全崩了。可能这也是大家讨厌写测试的原因之一吧。
Kent C. Dodds[1] 在这篇文章 《Common Testing Mistakes 》[2] 分享 了 3 个他看到的测试误区。今天，就把这篇文章分享给大家吧！
翻译中会尽量用更地道的语言，这也意味着会给原文加一层 Buf，想看原文的可点击 这里[3]。
误区一：测试代码的实现细节
说实话，我非常喜欢这个误区(详情可以看这里[4])，因为在测试过程中，它是一个很严重的问题，这样写测试也不会带给你对应的信心。下面是一个测试代码实现细节的例子：
// 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 个能完整跑通注册/登录的流程，那么你就不会失去这个登录注册流程的信心。
总结
一定要时刻记住我们写测试是为了提高代码信心。如果你现在做的事不能让你提高对代码的信心，那可以考虑你是否真的要这么做!
