TeamCity UI：我们如何测试它
开发一个可用的软件是很困难的。就像制造飞机一样，它需要有才华的人、工作部件和测试框架。在一切准备就绪、检查和复核之前，任何飞机都不能离开机库。
在JetBrains中，我们采用相同的理念来构建我们的软件。严格的测试帮助我们在最终产品起飞之前发现错误和问题。就像造飞机一样，软件开发是一个由多个阶段组成的过程。虽然这篇文章的作者不是航空航天工程师，但我们将使用简化的飞机类比。这有几个原因：飞机很漂亮，它是纯粹的工程，它揭示了我们在这里提出的问题并不是软件工程所独有的。
产品越大，步骤和模块就越多。要确保您的软件已准备就绪，需要测试每个模块，并将其与其他所有模块正确集成。如果设置正确，CI/CD服务有助于自动执行此过程。最重要的是，它们消除了以一次粗心大意的行为可能导致全面灾难而闻名的人为因素。
与人们普遍认为的相反，测试在前端开发中非常重要。继续这个类比，你的飞机不仅需要飞行-它还必须舒适地坐在里面！此外，它的外部影响飞机的飞行(空气动力学)。回到前端，这意味着您必须测试可用性和功能性。这使得前端测试成为必须。在本文中，我们将概述TeamCity中使用的UI测试。如果您对技术细节有任何疑问，请不要犹豫，尽管问我们。
这篇文章的每个部分都包含到有用资源的链接。其中一些导致公共TeamCity配置，您可以在其中检查我们如何测试前端。请随时以客人身份签到并四处看看。
UI测试不仅仅是关于单元测试的。有屏幕截图、行为、可访问性、性能、安全性和感知测试。下面列出了它们中的每一个。
让我们来考虑一下对问题的拦截。在JetBrains中，它在多个级别上工作，并且大多数都是基于CI/CD的。每个测试、每个部门、每个级别都参与了发现和报告问题的整个过程。以下图表显示了所有这些部分：
每个测试都会处理一些问题类别。最后，它帮助我们缓解问题。
例如，我们捕获的大量UI问题属于屏幕截图测试阶段。属于Linters/Unit/Render测试的问题较少。这并不意味着这些测试毫无意义。相反，这可能意味着我们在这些领域的工作做得足够好，可以防止大量的问题。
我们想在此提出的重点是：大家可以看到，质素保证部门只面对三分之一的问题。这意味着通过使用CI/CD，您可以帮助您的同事节省检查易于预测的问题的时间，而这些问题可能会被组织良好的测试系统捕获。
该图表并不是100%有代表性，每个版本的数字都是浮动的：某些级别可以消除比其他级别更多的问题。然而，它表明测试系统是非常重要的，即使单独的测试只涵盖一个案例。在这里，数量不等于质量：测试可以“只”找到一个bug，但是如果不注意，这个bug可能会使整个应用程序崩溃。
首先，我们应该说代码应该是干净和一致的，但这是有问题的。每个人对干净代码都有自己的理解。在JetBrains中，我们同意了200多条规则，以确保我们的代码客观上保持干净。因此，每当林特检测到问题时，我们都会收到来自IntelliJ Idea的警告。提到复杂的应用程序需要使用类型脚本、流、kotlin或原因的静态类型，这并不是多余的。我们，TeamCity团队，已经决定使用Flow。我们用来构建前端的第一个测试之一就是eslint/style int检查。它的目的不仅是查找代码样式问题，还包括遗漏变量、导入或非廉价/安全操作(如没有依赖项的Reaction Hooks)的问题。
当然，也有单元测试。这很简单：我们编写纯原子函数，然后断言它们的输出。如果输出正常，TeamCity会将其标记为绿色，并允许管道继续运行。
跨多个设备和平台显示一致的UI是我们的主要目标之一。我们需要确保正确显示所有组件，而不管使用的浏览器、布局或视口大小如何。这意味着要测试组件在不同配置中的可视呈现方式。屏幕截图测试就是这样做的。
在其中一个更新之后，评论部分已添加到未经授权的代理。那挺好的。但是想象一下，这种测试可以揭示元素的消失。这种情况时有发生，我们发现这项测试非常有用。虽然，快照测试，您很快就会熟悉，但在这种情况下也会有所帮助。
使用WebDriver API连接到服务器；此API允许我们以自动模式与网站交互-而无需真正的用户。
Yandex的实用工具Hermione使用WebDriver连接到Storybook，并在每个浏览器中拍摄选定区域的多个屏幕截图。
这些截图随后被放入一个文件夹，赫敏在那里将它们与使用Mocha的默认截图进行比较。
我们试图通过最小化不必要的渲染量来提高界面的性能。一般来说，Reaction在这方面做得很好。但是，有一些情况您应该记住：如果您更改了组件中的某些内容，Reaction会创建一个新组件，而不是修改原始组件。
假设您将新道具传递到一个组件中。为了保存重新渲染所需的资源，Reaction会检查传递的道具是否与以前的版本不同。如果它们相同，则不会进行重新渲染。不幸的是，我们中的许多人忘记了，在JavaScript中，具有相同内容的两个数组或对象是不同的实体(因为这些对象/数组将具有不同的引用)。结果，我们最终不必要地呈现相等的组件。
您可以使用Reaction开发人员工具启用Reaction更新突出显示。这将显示您的应用程序中的所有重新渲染。例如，有一些重新渲染器，它们在光标移动到Trends Page子组件上时发生。幸运的是，所有这些重现的人都是在这里。但想象一下，添加到这些重新渲染的应用程序将会多激发100个呢？
我们已经知道危险了。尽管如此，我们还是决定使用“为什么要渲染”来检查冗余渲染。令我们惊讶的是，我们发现了多个效率低下的情况。我们就是这么做的：
如果我们更改了存储区中的某些内容，我们将使所有组件(订阅此存储区)再次收集数据。使用mapStateToProps回调时会发生这种情况。
收集完数据后，我们将其传递给组件，并启动比较功能来检查道具是否已更改。
同时，我们知道虚拟操作实际上不会更改存储中的任何值，这意味着不应该向组件传递任何新的道具。
如果新的道具导致组件重新呈现，我们知道我们在不应该创建新对象/数组的地方创建了一个新对象/数组。太遗憾了!。
使用重新选取库，如果生成函数的所有参数保持不变，则可以对结果进行记忆。如果传递的参数与前面的参数相等，我们将接收的不是新对象，而是对旧对象的引用。不会进行重新渲染。
您可以通过冻结对象或数组来将其预定义为不可变的。下一次，每当您想要返回回退值时，都应该返回这个不可变的对象。它保证对此对象的引用始终相同，因此不会重新呈现该组件。
快照测试验证对重要组件的结构所做的任何更改都是有意的。再一次，让我们回到我们的飞机类比。假设我们有一架飞机的结构快照：它应该有一个机身、一个机翼和四个喷气发动机。突然，我们决定拆下其中一个喷气发动机，用涡轮机取而代之。虽然这可能是个好主意，但它不再适合我们的快照。因此，我们会收到通知。
在上图中，这一改变是故意的，具有明显的后果。现在想象一下我们的飞机的快照，它由数百个组件组成：跟踪所有的交互将非常困难。JavaScript项目在这方面类似。对一个组件的微小更改可能会给整个项目的结构带来不希望看到的后果。
您可以通过创建结构的快照来保护结构。无论何时打印错误、更改HTML类或添加新组件，都会破坏结构。如果您这样做，快照测试将通知您。检查下面的示例：
在这里，我们将发动机类型从涡扇改为螺旋桨。只是为了测试一下它是怎么工作的。由于新的搜索引擎不再与我们的快照匹配，因此测试失败。我们有一份报告，我们的工程师正在调查问题的路上。
e2e测试与试飞非常相似。就像飞机一样，我们必须确保我们的界面在现实世界中确实是可用的。由于数以千计的部件相互作用，在飞行员真正将飞机送入空中之前，你永远不会知道你的飞机是否能起飞。
e2e测试旨在从头到尾测试应用程序流。这些测试模拟一个真实的用户，该用户一遍又一遍地经历相同的特定用例。
根据用户的POV(用户情景)创建一个关键场景列表。
每个测试都应该描述Selenium应该如何与UI交互。声明：“确保用户在转到页面X并启动进程Y后获得窗口Z。”
写这篇文章花了一段时间。在此期间，我们实现了一些新的测试，例如依赖项安全审计、可访问性测试，我们还在讨论一些新的测试类别。我们期待您的反馈意见，以便继续撰写文章并更深入地研究前端测试领域。
TeamCity允许您为启动测试和部署构建创建无限复杂的逻辑。这就是TeamCity为其自己的UI显示构建链/时间线的方式。
如您所见，TeamCity并行运行测试，因此，一些构建会等待其他构建成功完成。如果出了问题，它可能会停止整个管道-只是为了防止在肯定会失败的测试上浪费资源。
这里重要的一点是，我们不仅可以建造复杂的管道，而且可以很好地使它们变得复杂、复杂。例如，我们流水线的某些部分必须构建在OS X代理上，其中一些必须构建在Linux系统上，而有些将使用Amazon Cloud代理构建。
你还记得第一张图吗？我们的自动化测试涵盖了一半以上的问题，而质量保证部涵盖了三分之一的问题。尽管如此，总会有一些东西留下来。在JetBrains中，我们广泛实践“狗脚”：我们使用自己的产品(IntelliJ、TeamCity、Space、YouTrack等)来开发和构建软件。所以，在这个阶段，JetBrains内部的每个人都可以来找我们，分享反馈。通过这样做，我们可以获得通知并修复通过所有其他过滤器的错误。
在我们的Early Access计划期间，您可以了解更多有关我们目前正在开发的新功能的信息，分享您的反馈，报告问题，并要求我们包括一些新功能，以便尽快发布。
希望我们已经明确了前端测试的基本原则。总而言之，你可以认为它是保险的：它需要一些努力，但可以挽救生命。为了从小规模项目的CI/CD中获得最大利润，您可以免费使用TeamCity。保护自己不会犯代价高昂的错误！
