需要对项目进行自动测试。 但是，正如他们所说，口味和颜色的自动化可能有所不同。 我们来到一个已经存在自动测试的项目，并且能够在不进行根本性变革的情况下提高覆盖率并加速测试的通过。 在猫下，我们是如何做到的。
关于项目的几句话
尽管由于保密协议，我们无法透露该项目的细节，但总的来说，任务如下。 我们加入了fintech API服务的开发，该服务与数据库进行交互，并返回必要的财务对象（价格，关税等）。 我们的任务是测试此服务的移动客户端-Web和本机移动应用程序。
随着项目的复杂性，该项目的测试自动化逐渐发展。 这可能是一次在我们的项目中发现的端到端测试出现的时间。 由于服务已经更改，并且当时没有人支持测试，因此大多数人到那时都无法使用-唯一的自动化工程师在我们到达之前就离开了该项目。
甚至那些似乎与功能相对应的测试有时也会因版本混淆或外部资源不可访问而失败。 为了进行测试，使用了单独的基础结构-测试台，其中部署了必要的版本进行实验。 不同的工作组可以使用它，并且他们并不总是一致行动。 由于一组人员的行为，我们的服务使用的一些重要API可能会掉线，因此，即使是有效的测试也无法通过。 即 测试不再显示服务本身的可服务性，而是与整个测试基础结构相关。
我们如何陷入混乱
在这种情况下，似乎有必要放弃所有旧的成就并重新进行测试。 但是我们的行为更加“人性化”。 测试结构本身被保留下来，专注于解决特定的问题-测试的缓慢通过，测试的不稳定和测试用例的覆盖范围不足。 对于他们每个人都有一个解决方案。
重构
首先，我们依靠更现代的设计模式对旧测试的代码进行了部分重新设计。
遗留代码的一部分必须删除-太难维护了。 在另一部分中，我们发现了所有弱点-我们将正常睡眠者替换为默认睡眠，通过测试运行者的注释为全局设置中的所有测试做准备，等等。 许多小步骤将平均端到端测试通过时间从3-4分钟减少到1-2分钟。
原子方法
为了加快创建新测试并简化对旧测试的支持，我们从繁琐的端到端案例中解脱出来。
就个人而言，我从根本上不反对端到端测试，但是，如果您需要检查一个特定的屏幕（甚至屏幕上的部分信息），那么从用户授权开始的所有步骤都太昂贵了。 想象一下，我们正在测试一个在线商店，我们只需要检查购买某种产品后将发送给买方的支票。 与其从系统中仅获取一个屏幕，不如通过登录名和密码，选择产品，确认购买等。 -将执行许多与特定测试任务无关的步骤。 但是每一步都需要时间。 即使进行了所有优化，端到端测试的启动也要花费2分钟，而对特定屏幕的验证只需要10秒。 因此，在可能的情况下，我们继续进行此类“原子”检查，仅指测试案例中我们感兴趣的屏幕。
在此过程中，仅出于屏幕比较的目的，我们实施了快照测试，可让您检查大部分UI。 在一个存储库中拥有测试和应用程序代码，我们可以在测试中使用该应用程序的方法，即 举起此过程所需的任何屏幕。 因此，我们在将测试屏幕截图与参考屏幕截图进行比较时会发现错误。
现在，我们有大约300个快照测试，并且它们的数量正在逐渐增加，因为这种方法可以大大减少在将最终版本发送到生产环境之前检查完成版本的时间。 整个测试过程在打开请求请求时自动开始，并在40分钟内运行-因此开发人员可以迅速收到有关当前分支中问题的反馈。
当然，保留了许多端到端测试。 在需要验证大型业务场景的情况下，不能没有它们，但是在所有细节均已验证后运行它们是有意义的。
嘲笑
为了排除不稳定的测试平台对测试结果的影响，我们启动了一个模拟服务器。 关于我们当时考虑的决定以及为什么选择Okhttpmockwebserver，
我已经在Habré上写道 。
结果，由于测试的外部原因导致的流行性摔倒的比例显着下降。
Kotlin DSL
同时，我们使测试更具可读性。
那些参与UI测试的人都知道，在测试的长“足迹”（尤其是在端到端测试阶段）中，很难找到一堆定位符中的真相。 当您从事了两年的项目时，很容易在其中导航，甚至在半夜也可以记住是什么。 但是，如果您只是来，进入正在发生的事情是一项单独的大任务。 为了使新人们不必每次都处理它，我们决定改用Kotlin DSL。 它的实现非常简单，并且结构简单易懂。 以前，测试由一组相同的低级调用组成-单击，文本输入，滚动，但是现在所有这些都变成了更多的“业务”-类似于BDD方法。 一切都是可见且可理解的。
我认为，这使我们对未来有一定的保留。 这个项目曾经面临过一位自动化工程师的离职。 对于测试，这并没有以最好的方式结束-他们只是停止了对它们的支持，因为事实证明入门门槛太高了。 理解这样一个干燥的代码需要很多时间和一定的资格。 我们对测试进行了重新设计，以便可以随时将人员从其他项目或从手动测试转移到自动化。 几乎任何人都可以在Kotlin DSL上编写最简单的测试。 因此，自动化可以离开底层的实现，并快速编写新的简单测试以连接功能团队中的人员。 他们具有足够的业务逻辑知识，并且该项目将受益于他们将更多地参与编写自动测试过程的事实。 Kotlin DSL允许您准确地描述测试用例，就像他们希望看到所有检查一样，从而使方法的低级实现不在其工作范围之内。
通常，所有这些使更快地增加自动测试的覆盖范围成为可能。 如果更早地实现新测试套件需要16到20个小时，那么采用新方法，根据测试的复杂性，它需要4到12个小时（支持的人工成本从16到24个小时减少到8到12个小时）。周）。
文章作者：Ruslan Abdulin。
PS：我们在Runet的多个站点上发表文章。 订阅我们在
VK ，
FB ，
Instagram或
Telegram频道上的页面，以了解我们的所有出版物和其他Maxilect新闻。
PPS帮助我们使博客文章更加有趣：
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform 。