前言大家好，我是海怪。在做前端测试时，选择合适的测试策略远比野外测试重要，所谓“方向>努力”。如果选择了错误的测试策略，很容易编写出可维护性差、不稳定的测试用例。一旦业务发生变化，用例全部崩溃。也许这就是人们讨厌编写测试的原因之一。KentC.Dodds分享了他在这篇文章[《Common Testing Mistakes》](https://kentcdodds.com/blog/c...《Common Testing Mistakes》)中看到的3个测试错误。今天把这篇文章分享给大家~我会尽量在翻译中使用更地道的语言，也就是在原文的基础上加一层Buf。如果您想阅读原文，请点击此处。正片开头的误区一：测试代码的实现细节说实话，我很喜欢这个误区（详见这里），因为在测试过程中这是一个非常严重的问题，写测试就像这不会给你带来相应的信心。这是一个测试代码实现细节的例子：//counter.jsimport*asReactfrom'react'exportclassCounterextendsReact.Component{state={count:0}increment=()=>this.setState(({count})=>({count:count+1}))render(){const{count}=this.statereturn{count}}}//__tests__/计数器.jsimport*asReactfrom'react'//React测试库很难测试代码实现细节，所以这里使用enzyme来测试import{mount}from'enzyme'import{Counter}from'../counter'test('incrementmethodincrementscount',()=>{constwrapper=mount()//永远不要这样做expect(wrapper.instance().state.count).toBe(0)wrapper.instance().increment()expect(wrapper.instance().state.count).toBe(1)})为什么说上面是被测代码的实现细节呢？而且，为什么测试代码细节不好？像上面这样对实现细节的过度测试会带来两个结果：我可以在测试完全通过时使业务代码崩溃（例如在分配onClick时故意写错变量名）我可以在重构业务代码时崩溃测试用例（对于例如，如果将increment重命名为updateCount，测试会崩溃，但是业务代码会正常运行），因为业务逻辑没有变，但是实现方法变了）像这样的测试用例是最难于维护，因为你要不断更新它们（基于上面第二点），同时它们也不会给你更多代码的信心（基于上面第一点）误区二：100%代码覆盖率是另一个误解是强制要求100%的代码覆盖率。有趣的是，我经常看到一些项目要求100%的覆盖率。这个规定不管出自哪里，其实都是对代码覆盖率的误解，因为它没有给你相应的代码信心。代码覆盖率只能告诉你一件事：这行代码已经被测试用例运行了，但是它没有告诉你的是：代码是否按照业务需求正常工作，代码是否可以与测试用例中的其他代码一起工作。project,theprojectcrashes代码覆盖率的另一个问题是，每增加一行代码，整体覆盖率就会增加。也就是说，如果您想提高整体覆盖率，向“付款页面”添加测试与向“关于”页面添加测试具有相同的效果（更高的整体覆盖率）。另一个比这更严重的问题是：这样的覆盖率并不能让你深入了解你的项目......目前，没有一刀切的解决方案来获得准确的代码覆盖率，毕竟每个项目的需求都是不同的.我一般不会太关注代码覆盖率，而更关注项目的重要部分是否覆盖到位。在确定项目的关键部分后，我使用覆盖率报告来查找测试尚未覆盖的边缘案例。澄清一下，100%的代码覆盖率对于开源模块来说是完全合理的，因为它们通常更容易达到100%的覆盖率（项目小且相对简单），而且它们是重要的代码，将被许多其他项目引用。误区三：与集成测试和单体测试相比，重复测试，大多数人最多抱怨E2E慢，不可靠。你不可能让单个E2E测试跑得快，像单个测试一样稳定。无论如何，这是不可能的。不过话虽如此，单次端到端测试会比单次测试带来更多的代码信心。很多时候单元测试无法带来像E2E那样高的代码置信度，所以在项目中写一些E2E测试绝对是物有所值！当然，以上并不意味着我们不能让我们的端到端测试运行得更快、更可靠。其中，重复测试是人们在编写E2E测试时经常踩到的一个坑，会降低整个测试的性能和可靠性。我们应该孤立地进行测试。理论上，每个单独的E2E测试都应该像不同的用户在使用该软件一样执行。在这种情况下，每次运行测试时，您都必须通过注册和登录过程来创建一个新用户，对吗？好像是对的，然后每次都要点击按钮，输入用户信息注册登录，这只是为了在业务中使用用户的登录状态，对吧？错误的！这个不对！让我们退后一步思考：为什么要编写测试？因为通过这种方式，您可以交付更有信心且不太可能崩溃的项目！比如说，您有100个测试需要在登录用户的情况下执行。您应该运行注册/登录过程多少次才能说服自己代码没问题？100次还是1次？正常人都会选择1次，因为只要1次成功，哪里都应该成功。所以剩下的99个额外测试不会给你任何代码信心。他们只是在做无用的工作。那你该怎么办？现在我们已经设置了测试的隔离环境，同一个用户不应该在测试之间共享。我推荐的做法是：每次要注册登录新用户时，在项目中发送相同的HTTP请求！发送请求肯定比点击页面输入框输入用户名和密码要快，而且会产生更少的假错误（译注：假错误的意思是：测试失败，但实际上应用代码并没有错本身）。只要你能保证有一个流程可以完整的贯穿注册/登录，那么你就不会对登录注册流程失去信心。总结永远记住我们编写测试是为了提高代码的可信度，这一点很重要。如果您现在所做的并不能提高您对代码的信心，请考虑您是否真的想这样做！好了，这篇外文就为大家带来了。本文主要列举3个误区：避免过度测试代码细节，避免100%覆盖，避免重复测试。这三个误区都是因为我们没有搞清楚测试的本质：提高代码置信度。当你在痛苦地写测试用例的时候，那么很可能你已经钻到墙角，把测试写错了方向。这时候，你不得不停下来回头看看：如何提高自己的代码信心？喜欢我的分享可以来一波一键三连，点赞，看就是我最大的动力，爱??
