1. 首页
  2. IT资讯

如何知道要测试什么?

“u003Cdivu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F4debb7aba1304762b4295729697cbd04″ img_width=”715″ img_height=”803″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cp class=”ql-align-center”u003E图片来自Craig Whiteheadu003Cu002Fpu003Eu003Cpu003Eu003Cemu003E帮助你确定测试内容的实用建议。u003Cu002Femu003Eu003Cu002Fpu003Eu003Cpu003E知道如何测试是很了不起的,也是非常重要的。我创建了很多内容,教人们测试的基础知识,如何配置工具,如何为特定的场景编写测试,等等。但是,知道如何编写测试只是在你的应用程序中获得信心的战斗的一半。知道要测试什么是另一半非常重要的战斗。u003Cu002Fpu003Eu003Cpu003E在我的研讨会资料(https:u002Fu002Fkentcdodds.comu002Fworkshops )和TestingJavaScript.com上,我确实谈到了如何知道要测试什么,但是我被问到这个问题已经够多了,所以我觉得写一篇关于它的博文可能会更好。就是这样了!u003Cu002Fpu003Eu003Ch1u003Eu003Cstrongu003E记住我们为什么要测试u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003Eu003Cstrongu003E我们编写测试是为了确保当用户使用我们的应用程序时它们能够正常运行。u003Cu002Fstrongu003E有些人编写测试是为了增强他们的工作流,这很好,但是我对增强信心更感兴趣。既然如此,我们的测试就应该直接映射到增强我们的信心上。下面是我希望你在编写测试时考虑的关键点:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E少考虑你正在测试的代码,多考虑代码支持的用例。u003Cu002Femu003Eu003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E当你考虑代码本身时,开始测试实现细节就变得太容易也太自然了(但这将导致灾难)。(https:u002Fu002Fkentcdodds.comu002Fblogu002Ftesting-implementation-details )u003Cu002Fpu003Eu003Cpu003E但是,考虑用例会让我们以更接近于用户使用应用程序的方式编写测试:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E你的测试与软件的使用方式越相似,它们就能给你带来越多的信心。——我的Twitter文u003Cu002Femu003Eu003Cu002Fstrongu003E(https:u002Fu002Ftwitter.comu002Fkentcdoddsu002Fstatusu002F977018512689455106 )u003Cu002Fpu003Eu003Ch1u003E代码覆盖率<用例覆盖率u003Cu002Fh1u003Eu003Cpu003E代码覆盖率是一个度量标准,它向我们显示在测试期间正在运行的代码行。我们以这段代码为例:u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F922c0d05c15b48ff91cbb7e28a6fa466″ img_width=”718″ img_height=”262″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E目前,我们还没有对这个函数进行测试,所以我们的代码覆盖率报告将表明我们对这个函数的覆盖率为0%。这个用例中的代码覆盖率报告让我们意识到测试是需要的,但它并没有告诉我们这个函数的什么地方是重要的,u003Cstrongu003E也没有告诉我们这个函数支持哪些用例u003Cu002Fstrongu003E,这是我们在编写测试时需要着重考虑的。u003Cu002Fpu003Eu003Cpu003E事实上,当我们考虑整个应用程序并想知道要测试什么时,覆盖率报告在帮助我们深入了解应该将大部分时间花在什么地方这方面几乎毫无帮助。u003Cu002Fpu003Eu003Cpu003E因此,覆盖率报告只能帮助我们确定代码库中哪些代码缺少测试。因此,当你在查看代码覆盖率报告并注意到缺少测试的代码行时,不要考虑ifsu002Felses、循环或生命周期。相反,要问问自己:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E这些代码行支持哪些用例,我可以添加哪些测试来支持这些用例?u003Cu002Femu003Eu003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E“用例覆盖率”会告诉我们我们的测试支持多少用例。不幸的是,现在还没有自动化的“用例覆盖率报告”这样的东西。我们得自己创建。但是代码覆盖报告有时可以帮助我们识别我们还没有覆盖的用例。我们来试一下它。u003Cu002Fpu003Eu003Cpu003E因此,如果我们阅读代码并思考一下,我们就可以确定要支持的第一个用例:“如果给定一个数组,它将返回一个数组。”这个用例语句实际上是我们的测试的一个很好的标题。u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F79c032a72e3f4bd2841c0fa06d8cff11″ img_width=”743″ img_height=”101″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E有了这个测试,我们的覆盖率报告看起来像这样(高亮显示的行是被覆盖的):u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F4a23aa26b6fe40ecb6fc90a2e55cd928″ img_width=”718″ img_height=”261″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E现在,我们来查看一下剩余的行,并且可以确定还有两个以上的用例我们的测试还不支持:u003Cu002Fpu003Eu003Culu003Eu003Cliu003E如果给定一个falsy(虚)值,它将返回一个空数组u003Cu002Fliu003Eu003Cliu003E如果它不是一个数组或falsy值,它将返回一个带有给定参数的数组u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E我们来为这些用例添加测试,看看它如何影响代码覆盖率。u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002Fc9d1991a85b84ddfb2b872c3e2fa4e19″ img_width=”722″ img_height=”380″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E好了,差不多了!u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002Ff5540103a34842608c3b07f475c7f306″ img_width=”627″ img_height=”102″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F29ba54a373cd492faff6ee0dbf3d5cbc” img_width=”720″ img_height=”262″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E太酷了!现在我们可以确信,只要我们不需要更改这个函数的用例,我们的测试就会继续运行直到通过。u003Cu002Fpu003Eu003Cpu003E代码覆盖率并不是一个完美的度量标准,但是它可以作为一个有用的工具来确定代码库中哪些部分缺少“用例覆盖率”。u003Cu002Fpu003Eu003Ch1u003E代码覆盖可以隐藏用例u003Cu002Fh1u003Eu003Cpu003E有时,我们的代码覆盖率报告会显示100%的代码覆盖率,但并不是100%的用例覆盖率。这就是为什么有时我甚至会在开始编写测试之前就试图考虑所有的用例。u003Cu002Fpu003Eu003Cpu003E例如,我们假设arrayify函数是这样实现的:u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002Fdabda5dd49f44794ba748ef95322c41c” img_width=”715″ img_height=”208″ alt=”如何知道要测试什么?” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E这样,我们就可以通过以下两个用例来获得100%的覆盖率:u003Cu002Fpu003Eu003Culu003Eu003Cliu003E如果给定一个数组,它将返回一个数组u003Cu002Fliu003Eu003Cliu003E如果不是数组,它将返回一个带有给定参数的数组u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E但是如果我们能看一下用例覆盖率报告,它会表明我们忽略了这个用例:u003Cu002Fpu003Eu003Culu003Eu003Cliu003E如果给定一个falsy值,它将返回一个空数组u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E这可能很糟糕,因为现在我们的测试没有给我们足够的信心,让我们相信当用户像这样使用arrayify()时,我们的代码能够正常工作。现在,它很好,因为即使我们没有对它进行测试,我们的代码也支持那个用例。但是我们在适当的地方进行测试的原因是确保代码继续支持我们想要它支持的用例,即使事情发生了变化。u003Cu002Fpu003Eu003Cpu003E所以,我们举个例子来说明遗漏这个测试是如何导致错误的,有人可能会过来,看到.filter(Boolean)之类的东西,然后想:“嗯,这太奇怪了……我怀疑我们是否真的需要它。”所以他们删除了它,我们的测试继续通过,但是任何依赖于错误行为的代码现在都被破坏了。u003Cu002Fpu003Eu003Cpu003E关键要点: u003Cstrongu003E测试用例,而不是代码。u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Ch1u003E这如何应用于React?u003Cu002Fh1u003Eu003Cpu003E在编写代码时,请记住你已经需要支持两个用户:最终用户和开发人员用户。同样,如果你考虑的是代码而不是用例,那么开始测试实现细节就变得非常危险。当你这样做时,你的代码就有了第三个用户。u003Cu002Fpu003Eu003Cpu003E下面是人们经常考虑的关于React测试的几个方面,这些测试会导致实现细节测试。对于所有这些测试,与其考虑代码,还不如考虑代码对最终用户和开发人员用户的可见效果,那就是你的用例,测试它吧。u003Cu002Fpu003Eu003Culu003Eu003Cliu003E生命周期方法u003Cu002Fliu003Eu003Cliu003E元素事件处理程序u003Cu002Fliu003Eu003Cliu003E内部组件状态u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E相反,你应该测试以下内容,因为它们涉及到你的两个用户。这些内容中的每一个都可以改变DOM,发出HTTP请求,调用prop回调函数,或者执行其他一些u003Cemu003E可观察到的 u003Cu002Femu003E附加作用,这些附加作用对测试非常有用:u003Cu002Fpu003Eu003Culu003Eu003Cliu003E用户交互(使用来自react-testing-library的fireEvent):最终用户是否能够与组件渲染的元素交互?u003Cu002Fliu003Eu003Cliu003E改变prop(使用来自react-testing-library 的rerender):当开发人员用户使用新的prop重新渲染组件时会发生什么?u003Cu002Fliu003Eu003Cliu003E上下文更改(使用来自react-testing-library 的rerender):当开发人员用户更改上下文导致组件重新渲染时会发生什么?u003Cu002Fliu003Eu003Cliu003E订阅更改:当组件订阅的事件派发器改变时会发生什么?(如firebase、redux商店、路由器、媒体查询或基于DOM的订阅,比如在线状态)u003Cu002Fliu003Eu003Cu002Fulu003Eu003Ch1u003E我如何知道在一个app中从哪里开始?u003Cu002Fh1u003Eu003Cpu003E因此,我们知道怎样去考虑要对单个组件,甚至我们app的页面测试哪些东西,但从哪里开始呢?这有点困难。尤其是当你刚刚开始在一个大型应用程序中进行测试时。u003Cu002Fpu003Eu003Cpu003E那么这就是你要做的,从用户的角度考虑你的app,然后问自己:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E如果这个app出问题了,哪个部分最让你心烦意乱?u003Cu002Femu003Eu003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E或者,更普遍地来说:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E在这个app中,什么事情发生错误是最糟糕的?u003Cu002Femu003Eu003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E我建议你做一个你的应用程序支持的特性列表,并根据这个标准对它们进行优化。这对你的团队和经理来说是一个很好的锻炼。这次会议的附加作用是帮助房间里的每个人理解测试的重要性,并有希望说服他们,在你需要做的所有其他特性工作中,测试应该得到某种程度的优先级。u003Cu002Fpu003Eu003Cpu003E一旦你有了这个优先级列表,那么我建议你编写一个单独的端到端(E2E)测试,以覆盖大多数用户在特定用例中经历的“幸福之路”。通常,你可以通过这种方式覆盖你的列表中几个最重要特性的部分。这可能需要一段时间来建立,但它绝对是物超所值。u003Cu002Fpu003Eu003Cpu003EE2E测试不会给你100%的用例覆盖率(你甚至都不应该尝试),也不会给你100%的代码覆盖率(无论怎样,你都不应该对E2E测试记录这一点),但它会给你一个很好的起点,在很大程度上会增强你的信心。u003Cu002Fpu003Eu003Cpu003E一旦你写好了几个E2E测试之后,那么你就可以开始为这些E2E测试中缺少的一些边缘用例编写一些集成测试,并为这些特性所使用的更复杂的业务逻辑编写单元测试。从这里开始,就是随着时间添加测试的事情了。只是不要为实现100%的代码覆盖率报告而烦恼,这不值得花时间。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E要了解更多关于建立测试文化和合理的代码覆盖目标的信息,我建议你观看u003Cu002Femu003Eu003Cu002Fstrongu003EAaron Abramov在AssertJS 2018上的演讲:使用软件设计原则建立测试模式(https:u002Fu002Fwww.youtube.comu002Fwatch?v=_pnW-JjmyXE&list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw )。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Eu003Cemu003E请在这里阅读更多关于“不同类型测试之间的区别”的信息:u003Cu002Femu003Eu003Cu002Fstrongu003E 前端应用程序的静态测试、单元测试、集成测试和E2E测试(https:u002Fu002Fkentcdodds.comu002Fblogu002Funit-vs-integration-vs-e2e-tests )。u003Cu002Fpu003Eu003Ch1u003E结论u003Cu002Fh1u003Eu003Cpu003E给你足够的时间和经验,你就会形成一种直觉,知道要测试什么。你可能会犯错误,还会有点挣扎。但别放弃!继续。祝你好运。u003Cu002Fpu003Eu003Cblockquoteu003Eu003Cpu003E英文原文:https:u002Fu002Fkentcdodds.comu002Fblogu002Fhow-to-know-what-to-test u003Cu002Fpu003Eu003Cpu003E译者:一瞬u003Cu002Fpu003Eu003Cu002Fblockquoteu003Eu003Cu002Fdivu003E”

原文始发于:如何知道要测试什么?

主题测试文章,只做测试使用。发布者:熱鬧獨處,转转请注明出处:http://www.cxybcw.com/10844.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code