测试Vue应用程序简介关于计算机专业vuex.js介绍概述的毕业设计论文英文英语外文文献翻译成品资料（中英文双语对照）

本文是中英对照毕业设计论文外文文献翻译，下载后直接可用！省去您找文献、pdf整理成word以及翻译的时间，一辈子也就一次的事！文献引用作者出处信息:EddYerburghTestingVue.JsApplications,2019(如年份太老，可改为近2年，很多毕业生都这样做，毕竟外文翻译要求也不高)了，可自行删减，大多数学校都是要求选取外文的一部分内容进行翻译的。）1.1.DEFININGTESTING1.2.TESTINGOVERVIEW1.3.WRITINGAHACKERNEWSAPPLICATIONHackerNewsclone.components.SUMMARY测试Vue应用程序简介本章将涵盖什么是测试为什么测试有用单元测试、端对端测试和快照测试之间的区别Vue核心概念作为开发人员，您希望发布无错误的代码。没有什么比在星期一早上发现您上周五在应用程序上所做的更改中发现了错误更糟糕的了！确保应用程序正常运行的唯一方法是对其进行测试，因此了解如何彻底测试应用程序至关重要。好的测试方法可以加快开发速度，提高代码质量并限制应用程序中的错误。不良的测试方法会使项目瘫痪。本章将教您有效地测试Vue应用程序，以确保获得良好的测试效果并避免漏洞。到本书结尾时，您将成为Vue测试的高手，可以测试遇到的任何Vue应用程序。要学习测试Vue应用程序的技术，您将要从头到尾编写一个针对HackerNews克隆的测试套件。就像大多数大型Vue应用程序一样，HackerNews应用程序将使用Vue、Vuex、VueRouter和服务器端渲染。除了教给您技术之外，我还想教给您我多年来开发的心态和测试方法。在整本书中，我会为您提供一些磨练测试技能的建议。第一章是测试Vue应用程序的入门。我将为您提供测试的总体概述，本章你将学习到各种测试类型以及您将编写HackerNews应用。最后，我将解释一些Vue核心概念，以确保我们使用的术语相同。首先要做的是定义测试。任何值得一提的学术论文都会在深入讨论它们之前定义其使用的概念。因此，就像一位优秀的学者一样，在向您介绍不同的测试技术之前，我将通过测试应用程序来定义我要表达的意思。一个简单的定义是，测试应用程序是检查应用程序运行是否正确的过程。毫无疑问，您应该验证应用程序的运行是否正确，但是当您谈论不同的测试技术时，该主题会变得更加有趣。有两种主要的测试方法：手动测试和自动测试。手动测试是通过自己与应用程序进行交互来检查应用程序是否能正常工作。自动化测试是编写程序为您执行测试的一种做法。本章大部分内容是关于自动化测试的。但是要了解自动化测试的好处，您需要了解手动测试。每个可雇用的开发人员都要手动测试代码。这是编写源代码之后的下一个逻辑步骤，例如咀嚼食物后如何将其吞下。假设您要创建一个注册表单。完成编写代码后，您不仅会关闭文本编辑器，并告诉老板您已经完成了表单。不，您将打开浏览器，填写表格，并确保它正确完成了注册过程。换句话说，您将手动测试代码。手动测试非常适合小型项目。如果您有TODO清单应用程序，可以在两分钟内手动检查，则无需进行自动测试。但是，当您的应用增长到一定大小时，依靠手动测试就成为一种负担。让我告诉您有关我工作的第一个大型JavaScript应用程序的信息。该应用程序一团糟。您听说过意大利面代码吗？该代码是将意大利面条，意大利面条和意大利面条代码合二为一的。遵循应用程序逻辑非常困难，并且没有任何自动化测试。不用说，代码中有bug。为了阻止错误，我们将在发布应用程序之前对其进行手动测试。每个星期三，我们都会倒咖啡，打开用户测试旅程清单，并弯腰笔记本电脑四个小时，以完成这组说明。真痛苦考虑到我们花了10％的开发时间来手动测试该应用程序，您可能会以为我们会停止将任何bug投入生产。不。该应用程序充满了他们。原因是手动测试数百个功能很困难-太容易失去专心而忘记检查某些东西。有一次，在进行用户旅程时，我不小心忘记了单击一下按钮是否会显示音乐曲目的元数据。其他开发人员一定也忘记测试该功能，因为该错误已经存在了几个月！尽管我们的一些手动测试时间花在了测试新功能上，但大多数人还是花了测试旧功能来检查它们是否仍然有效。这种测试称为回归测试。回归测试对于我们人类来说是一项艰巨的任务-它们是重复性的，需要大量关注，并且没有创造性的投入。简而言之，它们很无聊。幸运的是，计算机可以胜任这些任务，而这正是自动化测试的用武之地！自动化测试是使用程序检查软件是否正常运行的过程。换句话说，您编写了额外的代码来测试您的应用程序代码。编写测试代码后，您可以轻松进行任意多次测您可以使用许多不同的技术来编写自动化测试。您可以编写程序来自动化浏览器，直接在源代码中调用函数，或者比较渲染的应用程序的屏幕截图。每种技术都有不同的优点，但是它们都有一些共同点：与手动测试相比，它们可以节省您的时在上一节中，我谈到了一个未经测试的应用程序。该应用程序的问题之一是，每次我们要发布该应用程序的新版本时，我们都要进行四个小时的手动测试。我加入团队后不久，CTO决定我们应该编写自动化测试来为我们完成这项工作。随着时间的流逝，我们将测试时间从四个小时的手动工作减少到20分钟的自动工作。积累了这些经验之后，我从一开始就一直为大型项目编写自动化测试。驯养一匹与人类同生的马匹要比驯服野马要容易得多。在本书中，您将学习根据应用程序的概念编写测试来创建驯服应用程序。自动化测试非常适合检查您的应用程序是否仍然有效。它们还使查看应用程序的代码更改更加容易。让我们看一下使用自动化测试的真实示例-在GitHub上测试请求请求。GitHub是一个托管Git存储库的网站。Vue等许多开源项目都托管在GitHub上，而我工作的大多数公司都将其代码保存在私有GitHub存储库中。如果没有测试，则在查看拉取请求时，需要将代码更改拉到计算机上，运行应用程序，然后手动测试代码以验证其是否仍然有效。这很耗时，当听到某些人在审核请求请求时完全跳过此过程时，您不会感到惊讶。自动化测试使此过程变得更加容易。在项目中进行自动化测试后，可以设置服务来下载拉取请求分支，运行测试套件并报告测试是否通过（图1.1）。只要您信任测试，就无需在自己的计算机上检查代码。大多数开源项目要求开发人员在添加新功能时编写新测试。Vue仅接受包含测试新代码的拉取请求。除了使拉取请求更易于审核之外，自动化测试还使现代化的工作流程（如持续集成和持续交付）成为可能。如果您对这些工作流程感兴趣，可以在MartinFowler的博客（http://mng.bz/nxVK）上阅读有关它们的信息。现在，我已经定义了自动测试和手动测试，是时候更具体了。下一节概述了自动测试技术，以及如何使用它们来检查应用程序。到目前为止，我已经谈到了高级测试。现在该讨论您可以编写的特定测试类型。在本书中，您将学习为前端应用程序编写三种类型的测试：单元测试，快照测试和端到端测试。端到端测试是最直观的测试类型。在前端应用程序中，端到端测试使浏览器自动化，以从用户的角度检查应用程序是否正常运行。假设您正在编写一个计算器应用程序，并且要测试它是否正确地将两个数字相加。您可以编写一个端到端测试，以打开浏览器，加载计算器应用，单击1按钮，单击加号（+）按钮，再次单击1按钮，单击等于（=）并检查屏幕显示正确的结果（2）。在下一个清单中，您可以看到一个示例代码。1在浏览器中导航到本地运行的应用程序2单击计算器按钮3断言计算器显示正确的结果端到端测试可以节省大量时间。编写完端到端测试后，可以根据需要多次运行它。想象一下，一套数百种这样的测试可以节省多少时间！首先，端到端测试似乎是您唯一需要的测试工具。但是它们有一些问题。首先，端到端测试很慢。启动浏览器可能需要几秒钟，并且网站响应速度可能很慢。一组端到端测试通常需要30分钟才能运行，并且如果您完全依靠端到端测试，那么您的测试套件将需要花费数小时才能运行。端到端测试的另一个问题是调试它们可能很困难。要调试端到端测试，您需要打开浏览器并逐步完成用户过程以自己重现该错误。当您在本地运行端到端测试时，这已经很糟糕了，但是如果您的测试在CI服务器上失败，而不是在本地计算机上失败，那么您的日子将会很糟糕。端到端测试还有另一个问题-它们可能很不稳定。不稳定测试是即使测试的应用程序正在运行也经常失败的测试。也许代码执行时间太长，或者API暂时关闭。就像片状的朋友一样，您将不再认真地对待片状的测试。“哦，不，测试失败了！让我看看。。。。哦，就是那个。一个人一直失的测试会使您的测试套件失去用处，但是在编写端到端测试时很难避免！如果您列出了开发人员所抱怨的所有内容，那么我将把钱花在排名前三的端到端测试中。尽管它们很有用，但它们不应该是您唯一的测试类型。在本书中，只有一章专门用于端到端测试，部分原因是端到端测试的缺点，部分原因是端到端测试与框架无关，无论您的应用程序是否编写，它们都可以工作使用Vue或MooTools。端到端测试使您可以手动执行的测试自动化。您可以将它们设置为定期在实时网站上运行，也可以在合并到master分支之前针对代码运行它们。端到端测试并没有为您提供一种测试代码的新方法-您可以获得更快的手动测试。另一方面，单元测试为您提供了一种新工具，您无法通过手动测试代码获得该工具。单元测试是针对应用程序的最小部分（单元）运行测试的过程。通常，您要测试的单元是功能，但在Vue应用程序中，组件也是要测试的单元（稍后将进一步介绍）。还记得计算器应用程序吗？在代码中，应用程序使用求和函数来计算两个数字的和。如果您编辑了该功能以使其易于阅读，则需要测试该功能是否仍可正常工作。您可以运行端到端测试，但是如果端到端测试失败，您将不知道问题是出在sum函数还是源代码的其他部分。您可以确定的唯一原因就是破坏了sum函数，那就是单独运行该函数。您可以通过单元测试来做到这一点。单元测试是在源代码中单独调用函数并断言它们行为正确的函数。看看下一个清单。这是一个简单的程序，可导入求和函数，运行该函数，如果sum不返回2，则会引发错误。2将求和函数导入测试文件3如果总和不返回，将引发错误24运行测试因为单元测试是针对隔离的单元运行的，所以当编写良好的单元测试失败时，它就像是闪烁的霓虹灯，将您引向问题代码。与端到端测试不同，单元测试是快速的。它们会在几秒钟内运行，因此您每次进行代码更改时都可以运行单元测试，以快速获得有关更改是否破坏现有功能的反单元测试的一个令人愉快的副作用是它们提供了文档。如果新开发人员开始一个项目并且需要知道代码单元的行为方式，则他们可以查看测试以确切了解单元的行为方式。我之前谈到过不稳定的端到端测试，这些测试即使应用程序运行正常也经常失败。编写良好的单元测试不会遇到这个问题。只要单元测试是确定性的，您就可以运行一千次，并且每次都会通过。到目前为止，关于单元测试，我只能说些好话了，我正在使它们脸红。但是我不想误导你。像端到端测试一样，单元测试也有其自身的问题。单元测试的一个大问题是它们使重构代码变得困难。如果您具有带有单元测试的复杂功能，并决定将功能拆分为两个单独的功能，则需要更改单元测试以及代码。这会使重构的吸引力大大降低。有时我不愿更改代码的结构，因为更新单元测试需要大量的额外工作。这里没有一个简单的解决方案，但是当您决定编写的测试是否可以长期节省您的时间时，还需要考虑一些其他事项。单元测试的另一个问题是它们仅检查应用程序的各个部分。您可以测试汽车的各个部分是否正常工作，但是如果不检查它们在装配在一起后是否正常工作，然后发动机没有打开，则测试无效。单元测试遭受这个问题。他们可以确保代码单元的行为符合预期，但不能测试这些单元之间是否可以正确交互。因此，您需要使用端到端测试来补充单元测试。到目前为止，我已经为您提供了端到端测试和单元测试的概述。您将在本书中学习的最终测试是快照测试。你玩过《发现差异》吗？“发现差异”是一款游戏，您拥有两张相同的图片，但它们之间的差异很小。游戏的目的是识别差异。快照测试类似于“发现差异”。快照测试会为您正在运行的应用程序拍照，并将其与以前保存的图片进行比较。如果图片不同，则测试失败。此测试方法是确保应用程序在代码更改后继续正确呈现的有用方法。传统的快照测试会在浏览器中启动应用程序，并对呈现的页面进行截图。他们会将新拍摄的屏幕截图与保存的屏幕截图进行比较，如果存在差异，则会显示错误。当操作系统或浏览器版本之间的差异导致测试失败（即使快照未更改）时，此类快照测试也会出现问题。在本书中，我将教您如何使用Jest测试框架编写快照测试。Jest快照测试可以比较JavaScript中的任何可序列化的值，而不是比较屏幕截图。您可以使用它们来比较Vue组件的DOM输出。您将在第12章中详细了解快照测试。现在，您已经看到了要编写的每种测试类型。现在该讨论如何组合这些不同的测试类型以编写有效的测试套件。如果将糖，面粉和黄油的混合量正确混合，则会得到美味的曲奇面团。如果使用错误的数量，则会得到面粉。您需要以正确的数量将不同类型的测试组合在一起，以确保您拥有一个强大的测试套件，而不是一堆测试代码。金字塔的大部分都包含单元测试-它们在开发应用程序时提供快速反馈。快照测试也可以快速运行，但是覆盖范围比单元测试要多，因此您不需要像单元测试一样多的快照测试。如果您是经验丰富的开发人员，则可能听说过集成测试。集成测试是另一种类型的测试，通常与单元测试和端到端测试结合使用。我不建议为前端代码编写集成测试。前端的集成测试很难定义，编写和调试。人们对集成测试的定义有所不同，尤其是在前端。一些人认为在浏览器环境中运行的测试是集成测试。有些人认为任何测试具有模块依赖性的单元的测试都是集成测试。有人认为任何完全渲染的组件都是集成测试。在第13章中，我将教您如何编写服务器端集成测试（使用我自己的定义以确保服务器以正确的HTTP请求进行响应。但是对于本书中的前端测试，您不会编写任何集成测试。在现实生活中，有时我不为组件编写单元测试，有时在编写测试之前编写组件代码。TDD倡导者可能会惊恐地cl住自己的脸，但我发现对TDD采取僵化的方法会减缓发展。俗话说，生命是旅程，而不是目的地。尽管总的来说，这可能是正确的，但在开发应用程序的情况下却相反。只要编写节省时间的有价值的测试，编写它们的方式就无关紧要。对于本书的大部分内容，我都会告诉您要测试的内容，向您展示测试代码，然后向您展示可以通过测试的源代码。在添加以下源代码之前，运行测试时预期测试将失败。到目前为止，我已经向您介绍了自动化测试的好处，但是在您过度兴奋并创建一个自动化测试赞赏协会之前，有一个免责声明。自动化测试并非总是必要的。当我开始编写自动化测试时，我想测试所有东西。我亲身经历了未经测试的应用程序所带来的痛苦，并且像一个宿醉的中年男人一样，我下定决心不要再这样做了。但是我很快又吸取了教训。测试会减慢开发速度。编写测试时，请务必记住编写测试的原因。通常，测试的目的是节省时间。如果您正在从事的项目很稳定并且可以长期开发，那么测试会带来回报。但是，如果编写和维护测试所花的时间比保存您的时间长，那么您根本不应该编写测试。当然，在编写代码之前很难知道通过进行测试可以节省多少时间-随着时间的推移会学到这一点-但是例如，如果您要创建原型，从事短期项目，或在一家初创公司迭代一个想法，您可能不会从编写测试中受益。即使项目受益于测试，它可能也不需要您想像的那么多测试。让我告诉您有关100％代码覆盖率的谬误。代码覆盖率是对自动化测试运行代码库中多少行的度量。通常，代码覆盖率以百分比衡量：100％的代码覆盖率表示在测试执行过程中每行代码都会运行；0%的代码覆盖率意味着不执行任何行。这是一个有趣的测量，但可能会导致一些可怕的后果。测试提供的收益递减。这就像去健身房。初次去健身房时，您会迅速建立肌肉。每周只有三个小时的健身，几个月后，您可能会失去啤酒肚，看起来看起来很健美。但是，您获得的越大，则成长所需的时间就越多。您在健身房花费的时间越长，每增加一小时所获得的收益就越少。相同的原则适用于测试。您可以在几个小时内编写涵盖应用程序核心功能的简单测试。编写完这些测试后，增加代码覆盖率将变得越来越困难。如果您希望100%的代码覆盖率（对于某些开发人员来说是圣杯那将像用毛巾拧干最后一滴水一样。辛苦了在大多数情况下，100％的代码覆盖率并不是目标。当然，如果您正在开发任务关键型支付应用程序，其中的错误可能造成数百万美元的损失，那么100％的代码覆盖率将使您受益。但是根据我的经验，大多数应用程序都无法从100％的代码覆盖率中受益。在过去的几年中