当前位置:首页 > 天道酬勤 > 正文内容

jetbrains goland(jetbrains正版)

张世龙2021年12月20日 18:38天道酬勤1250

IDE界有“JB制造,一定是绝品! ”。 JetBrains以其高质量的IDE在广大程序员中享有声誉。 那么,不得不怀疑JB的高质量工具是如何开发测试的。

我对这个问题和大家一样感兴趣。 最近,JB博客曝光了那个TeamCity UI前端团队的软件测试做法,给了我们一点线索。 看了微知类,从此我们终于明白了如何制作那个精品软件。 那就是“像制造飞机一样开发软件”。

概述

开发精品软件不容易。 就像建造飞机一样,需要天才程序员、开发流水线和测试框架。 如果这一切都没有准备好,软件发布,飞机可以起飞之前,需要检查,不断检查确认。

在JetBrains中,用与制造飞机相同的理念构建软件。 严格的测试有助于在最终产品发布之前发现错误和问题。 就像制造飞机一样,软件开发是一个包括多个阶段的过程。 产品越大,步骤和模块就越多。 要确保软件已就绪,每个模块都必须经过测试并与其他模块完全集成。

CI/CD过程有助于该过程的自动化。 最重要的是消除人为疏忽引起的故障。

与一般看法相反,测试在前端开发也非常重要。 就像飞机一样,不仅要飞,坐起来也要舒服。 另外,其外观会极大地影响飞机的飞行方式。 的前端UI也同样需要测试可用性、交互性和功能。

UI测试不仅仅是单元测试。 另外还有屏幕快照、行为、可访问性、性能、安全性和感知测试。

通过测试系统和CI/CD,可以集中精力做真正重要的事情。

在JetBrains中,

问题分类

在多个级别上运行,大多数基于CI/CD。 各测试、各部门、各级在发布和报告问题的过程中发挥作用。 下图显示了APP中可能存在的y轴问题的数量,为图中的蓝条。 x轴表示了滤波器、问题的种类。 此图显示了不同的层如何影响问题的数量。

捕获的大量UI问题属于截图测试阶段。 问题少的部分属于Linters/Unit/Render测试。 当然,这并不意味着这些测试没有意义。 相反,这意味着在这些领域已经进行了足够的工作来防止许多问题。

这里的重点是质量保证部门面临三分之一的问题。 使用CI/CD可以节省检查容易预测的问题的时间。 这些问题可以在组织良好的测试系统中发现。

当然,该图表并不完全具有代表性,在发行版之间也发生了巨大的变化,在某种程度上可以解决更多的问题。 但是,即使个别测试只涵盖一种情况,测试系统也是非常重要的。

第二个数量和质量不一样。 虽然在测试中可能发现了唯一的错误,但如果不重视,则唯一的错误可能会导致整个APP崩溃。

人们常说

Linters, typings和单元测试

代码应该干净一致,这有问题。 每个人对漂亮的代码都有自己的理解。 为了确保代码客观清晰,JetBrains有200多条规则。 一旦Linters检测到问题,就会在IntelliJ Idea上发出警告。 TypeScript、Flow、Kotlin或Reason的静态类型是多余的,对于复杂的APP应用是必需的。 TeamCity团队使用Flow,构建前端的第一个测试只有eslint/stylelint检查。 目的不仅是寻找代码风格的问题,还包括变量丢失、import、non-cheap/safe操作(不依赖的React Hooks等)等问题。

当然,还有单元测试。 单元测试很简单。 创建纯原子函数,并声明其输出。 如果输出正常,则TeamCity将其标记为绿色,并继续执行CI管线。

截屏测试

的主要目标之一是在多个设备和平台上显示一致的UI。 小组不需要使用浏览器,而是必须确保所有组件(包括布局和视口大小)都已正确显示。 应该测试如何以不同的配置直观地显示组件。 这就是截图测试的主要工作。

任何一个更新都会将注释部分添加到错误的代理列表中。 没关系。 这个测试会明确元素的消失。 有时会发生。 小组发现这个测试很有用。

测试步骤如下。

1 .启动呈现组件的服务器(在本例中为Storybook )。

使用网页驱动程式应用程式

连接到服务器;API允许在没有真实用户的情况下以自动模式与网站进行交互。

3. WebDriver调用相关组件。

4. Yandex的实用工具Hermione使用WebDriver连接到Storybook,并在每个浏览器中获取所选区域的多个屏幕截图。

5. 然后将这些屏幕截图放到文件夹中,Hermione使用Mocha将其与默认屏幕截图进行比较。

6. 如果有什么变化,就发出通知。差异也以在可视化方式高亮显示。

React和渲染

通过减少不必要的渲染量可以提高接口的性能。对此, React非常擅长。但是,在某些情况下,需要注意:如果更改组件中的某些内容,React会创建一个新组件,而不是修改原始组件。

想象一下,将新的道具传递到组件中。为了节省重新渲染所需的资源,React检查所传递的道具是否与先前版本不同。如果它们相同,则不会进行任何重新渲染。然而,很多人可能会忘记在JavaScript中,两个数组或内容相同的对象是不同的实体(因为这些对象/数组将具有不同的引用)。结果,会导致不必要地对同样的组件进行了渲染。

为了解决此问题,可以对React Developer工具启用React Updates Highlighting。这样会显示应用中的所有重新渲染。例如,在光标移到趋势页面的组件上时会重新渲染。

但是如果真将这些添加应用程序将可能会触发一百次以上的渲染!

可以定使用why-did-you-render

(github/welldone-software/why-did-you-rendertests)检查冗余渲染。该组件帮助发现了很多效率低下的情况。具体步骤:

1. 创建了一个虚拟动作:它会触发对商店的更改。

2. 如果更改存储中的某些内容,将使所有组件(订阅此存储)再次收集数据。它发生在mapStateToProps回调中。

3. 收集数据后,将其传递给组件并启动比较功能以检查道具是否已更改。

4. 同时,虚拟动作实际上不会更改存储中的任何值,这样实际不会将新的道具传递给组件。

5. 如果新的道具导致组件重新渲染,就知道在不应该创建的地方创建了新的对象/数组。

为了解决这个问题的技巧,两个技巧:重新选择库和不变的数据结构。

重新选择库:

使用重新选择库,如果生成函数的所有参数都相同,则可以记住结果。如果传递的参数等于先前的参数,将不会收到新的对象,而会收到对旧对象的引用。不会进行任何重新渲染。

不变的数据结构:

可以通过冻结将对象或数组预定义为不可变的。下次,只要想返回一个预设值,就会返回该不可变对象。它保证了对该对象的引用始终是相同的,因此该组件不会被重新渲染。

快照测试

快照测试可验证是否对重要组件的结构进行了任何更改。拿飞机来类比。想象有一个飞机结构的快照:它有一个机身,一个机翼和四个喷气发动机。现在需要拆除其中一台喷气发动机,并用涡轮机代替。尽管这可能是个好主意,但它不再匹配快照。因此,就会收到通知。

如在上图中,变更是是主动的,有明显的后果。想象一下由数百个组件组成的飞机快照:跟踪所有交互非常困难。

JavaScript项目和这类似。对一个组件进行很小的更改可能会对整个项目的结构造成不良后果。可以通过创建快照来保护结构。每当打印错误,更改HTML类或添加新组件时,都会破坏结构。快照测试将通知是否这样做。

检查以下示例:

创建一个重要结构的快照,假定为IL-76LL引擎:

始终希望将未来的飞机与都会和前面的快照进行比较。

将发动机类型从涡轮风扇更改为涡轮螺旋桨发动机。只是为了测试它是如何工作的。由于新引擎不再匹配的快照,因此测试失败。将会创建一份报告,通知工程师检查该问题。

React组件与此相同:

E2E端测试

E2E测试与飞机试飞非常相似。与飞机一样,必须确保界面在现实世界中实际可用。由于成千上万的组件相互影响,永远无法在飞行员实际将飞机升空之前知道飞机是否可以起飞。

E2E测试旨在从头到尾测试应用程序流程。这些测试模拟了一个真实的用户,该用户一次又一次地通过相同的特定用例。

E2E测试流程如下:

1. 创建一个用户POV(用户故事)关键方案列表。

2. 为每个列出的方案创建一个自动化测试。

3. 这些测试中的每一个用例都描述Selenium应该如何与UI交互。

详细步骤描述:

打开浏览器。

登录。

转到第X页。

按下按钮Y。

确保显示窗口Z。

声明式描述:

"确保用户在转到页面X并开始过程Y之后获得窗口Z。"

4. 使用最后一个TeamCity实例启动Docker容器。

5. 启动测试;这些测试使用Selenium连接到Docker并执行算法。

其他测试

团队还实施了其他的一些测试,比如依赖安全审计(Dependencies Security Audit),可访问性测试,以及一些新测试类别也会陆续加入。

TeamCity和构建链

TeamCity使可以创建无限复杂的逻辑来启动测试和部署构建。这就是TeamCity如何显示其自己的UI的构建链/时间表的方式。

如图所见,TeamCity并行运行测试,因此,一些构建正在等待其他构建成功完成。而且,如果出现问题,则可能会中断整个流程,这只是为了防止浪费肯定会失败的测试资源。

下面是TeamCity如何可视化像大型项目的方式(以自己为例子):

重点是,TeamCity仅可以构建复杂的管道,而且可以良好地使它们复杂,复杂。例如,流水线的某些部分必须基于OS X代理构建,而某些则必须在Linux系统上构建,而其中的某些将要使用Amazon Cloud Agents构建。

结论

本文阐明了前端测试的基本原理和JB实践过程,包括Linters, typings,单元测试,截屏测试,React和渲染,快照测试,E2E端测试等一系列的自动化测试,像建造飞机一样,软件项目也是一项系统工程,需要严格的系统性流水线的自动测试来保证其质量,精品软件打造更是如此。

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/25807.html

分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。