12月6日至7日，第五届海森巴格会议在莫斯科举行。
她的口号是“测试。 我（以前是Java开发人员，现在是一家从未在QA工作过的小公司的技术负责人）在过去两年对Heisenbags的定期访问中，我在测试中学到了很多东西，并在我们的团队中实施了很多东西。 我想分享一次我记得这次报告的主观评论。
免责声明 当然，这只是根据我的个人喜好选择的报告中的一小部分（30个中的8个）。 几乎所有这些报告都以某种方式与Java有关，而没有一个关于前端和移动开发的报告。 在某些地方，我会让自己与演讲者发生争执。 如果您对更完整和中立的审核感兴趣，那么按照惯例，它应该出现
在组织者的博客上 。 但是，也许有人会发现自己无法找到的那些报告会很有趣。
文章中的照片来自会议的官方推特 。Baruch Sadogursky。 我们有DevOps。 让我们解雇所有测试人员
（照片中-Baruch发行《 Liquid Software》时的炒作）那些参与Java和参加JUGRU Group会议的人，Baruch Sadogursky不需要介绍。 但是，他第一次在Heisenbug演出。
简而言之-这是有关DevOps主要思想的审查报告。 观众仍然需要这种报告，因为当问到“给DevOps的定义”时，人们仍然首先回答“这是这样的人...”。
但是，即使是已经学习了有关此主题的人员，了解DORA协会
devops-research.com的研究也将非常有趣，该研究在具有不同绩效的团队中获得了各种体力劳动的百分比。 关于传递速度和质量的曲线（有时会降低速度，因为我们需要时间进行“更好的测试”，但是随着团队的发展，相关性就变得直接了）：
尽管报告的标题具有挑衅性，并且在时间表中将报告标记为“将要燃烧”类别，但我认为报告的内容是相当主流的。 当然，这不是关于在Devops转型条件下解雇测试人员，而是关于测试人员工作性质的改变。 一年前，
艾伦·佩奇 （
Alan Page）和尼古拉·阿里门科夫（Nikolai Alimenkov）谈到了很多事情。 一年前，在圆桌会议上讨论了变化的角色和T型技能的“水平”发展，“
测试人员在2018年应该知道什么 ”。
“当然，如果您不想更改，尽管没有那么有趣，但仍然有适合您的工作。 到目前为止，对于那些想要支持70年代用COBOL编写的系统的人来说，仍然有很多工作要做，” Baruch说。
阿尔索·埃罗申科（Artyom Eroshenko）。 需要重构项目吗？ 有一个想法！
Heisenbag参与者熟悉Artyom并提供有关Allure报告系统的报告（例如，
这是他在2018年从圣彼得堡的Heisenbag上
发表的有关Allure机会的
报告 ）。 魅力本身诞生于具有数千，数万甚至数十万个测试的项目的环境中，旨在简化开发人员和测试人员之间的交互。 它具有将测试与外部资源（例如票证系统）和版本控制系统中的提交链接的能力。 在我们的微型团队中，虽然测试数量只有几十个，但我们完全可以应付标准方法。 但是，随着其中一种产品的测试数量达到700次，并且总体任务是为客户创建高质量的报告，我开始将目光投向了Allure。
但是，此报告与魅力无关，尽管与他有关。
Artyom说服公众，为IntelliJ IDEA编写插件是一项简单而有趣的活动。 为什么要这样做？ 自动执行批量代码修改。 例如，要将大量源代码从JUnit4转换为JUnit5。 或者从使用“诱惑力1”到“诱惑力2”。或者通过与报价系统的通信来自动化测试的标记。
那些使用IDEA的人知道它可以用代码做什么技巧（例如，使用for循环将代码自动转换为使用Java Streams的代码，反之亦然，或者立即将Java转换为Kotlin）。 更为有趣的是，看看如何打开IDEA中代码转换的保密面纱，我们被邀请参与其中并根据我们的独特需求创建自己的插件。 下次，当我需要使用大型代码库进行操作时，我将回顾此报告，并了解如何使用IDEA中的通用插件将其自动化。
基里尔·梅尔库舍夫（Kirill Merkushev）。 Java和Reactor项目-测试怎么样？
在我看来，该报告很可能在Joker或JPoint Java会议上进行。 Kirill谈到了他如何在具有单个事件日志（Kafka）的微服务体系结构中使用
projectreactor.io框架，还谈到了在“反应流”上进行编码的本质，包括如何调试和测试使用该框架的应用程序。
生活也促使我们的团队使用具有单个事件日志的体系结构，并且我们还研究了Kafka。 但是，对于流事件处理，我们正在尝试使用Kafka Streams API（在我看来，对于开发人员而言，有状态处理之类的更多事情对于开发人员而言是开箱即用的），而不是Reactor。 但是，与新技术一样，“耙”和“陷阱”是事先未知的。 因此，重要的是要听听已经从事技术工作的专家的故事。
列昂尼德·鲁登科（Leonid Rudenko）。 使用Terraform管理Selenoid群集
如果以前的报告让人联想到JPoint会议，那么这份报告肯定是关于
DevOops的 。 Leonid讨论了如何使用Terraform规范来引发和配置Selenoid群集。 关于Selenoid本身是什么，去年的Heisenbug有
一份报告 -它是一个丰富的分布式系统，可以充当弹性服务，并允许您在各种浏览器中运行大量的Selenium测试。 与任何需要在多台机器上部署的系统一样，手动安装Selenoid也是困难的。 在这里，现代的“按代码配置”系统可以提供帮助。
Leonid对Terraform的功能进行了相当详细的概述-这个系统可能对大多数观众来说并不陌生，但实际上已经为DevOps-automation所熟知（例如，在Devoops-2018大会上
， Anton Babenko撰写
了一篇关于创建和维护代码的最佳实践
的出色报告。在Terraform上）。 此外，还显示了如何使用Terraform脚本为群集中的每台计算机使用带有Selenoid的docker容器来描述参数，以及群集虚拟机本身的参数。
尽管列昂尼德（Leonid）所考虑的特定案例肯定能够促进部署硒油醚的任务，但我并不同意所有事情的发言人。 本质上，它使用Terraform来完成两项不同的任务：创建资源并对其进行配置。 这就导致了一个事实，即Leonid被迫启动一次Terraform来创建虚拟机，而每个虚拟机又不得不一次在其上引发docker容器。 我认为Terraform可以很好地解决创建资源的问题，但不能很好地解决配置问题。 使用特殊的配置系统（例如Ansible或其他解决方案），可以避免terraform项目的繁琐及其多次启动。
但是总的来说，该报告作为针对基础结构即代码领域测试人员的“教育计划”，非常有用。
安德烈·马尔科洛夫（Andrey Markelov）。 使用全球SMS平台的示例，通过TestContainers和JUnit 5对微服务动物园进行优雅的集成测试
再一次关于微服务！ 这次，讨论的主题是如何运行需要同时启动和交互多个服务的测试。 提出将JUnit5及其
扩展系统和著名的（且出色的）TestContainers框架作为解决方案的基础（例如，参见
Sergey Egorov的去年报告 ）。
如果您正在用Java编写某些东西，但仍然不知道什么是TestContainers，那么我强烈建议您学习它。 TestContainers允许使用Docker技术直接在测试代码中拾取真实的数据库和其他服务，通过网络将它们连接起来，从而在测试启动时创建的环境中执行集成测试，并在测试结束后立即销毁它。 同时，一切都可以直接从Java代码运行，作为Maven依赖关系进行连接，并且不需要在开发人员的机器/ CI服务器上安装Docker以外的任何东西。 我们已经使用TestContainers一年多了。
Andrey展示了一个令人印象深刻的示例，说明了如何使用JUnit5扩展，自定义批注和TestContainers为端到端测试指定测试环境配置。 例如，在测试中编写注释（条件代码）
@Billing @Messaging
相对而言，我们可以写
@Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...}
这些参数将传递给Java接口，您可以通过这些参数与容器中提出的（测试开发人员未注意到的）真实服务进行通信。
这些示例看起来非常优雅。 对我来说，作为TestContainers和JUnit 5的活跃用户，它们是可以理解的，并且相对容易实现。
但是总的来说，使用这种方法，仍然存在一个重大问题，与配置测试和生产系统的方法根本不同的事实有关。
只有在端到端测试期间，不仅要测试整个系统，而且还要配置它的方式，才有可能在生产中实施快速发布而不必担心破坏一切。 如果我们在开发和测试过程中反复运行系统部署脚本，那么毫无疑问，即使在生产环境中启动该脚本也能正常工作。 在Andrey的示例中，配置测试环境的代码的角色由注释执行。 但是在生产中，我们使用完全不同的代码（Ansible，Kubernetes等任何东西）对系统进行了布局，而这种系统测试并未涉及任何方式。 这限制了这些测试，而这些测试并非完全端到端。
安德烈·格拉兹科夫（Andrey Glazkov）。 测试具有外部依赖性的系统：问题，解决方案，Mountbank
对于那些与本报告的主题相关的人员，我强烈建议您还观看
Andrei Solntsev所作的精彩演讲，介绍基于原理的方法来测试依赖于外部服务的系统。 Solntsev非常有说服力地谈到需要使用外部系统模拟进行全面测试。 Andrei Glazkov在他的报告中描述了用于这种润湿的系统之一-用NodeJS编写的Mountebank。
您可以将Mountebank提升为服务器，并通过与编写单元测试时对接口模拟进行“培训”的方式相似的方式，通过网络“培训”请求的答案。 唯一的区别是它是网络服务的模拟。 使用Mountebank的一个奇怪案例是能够将其用作代理-向真实的外部系统发送一些请求。
这里应该指出，我建议Java开发人员（和讨论区的Andrei同意）也考虑WireMock库，该库是用Java创建的，可以在嵌入式模式下运行，即直接从测试中运行而无需安装任何程序为开发人员的计算机或CI服务器提供服务（尽管它也可以作为独立服务器使用）。 与Mountebank一样，WireMock也支持代理模式。 我们在WireMock方面有一些积极的经验。
然而，Mountebank的优势在于支持较低级别的协议（WireMock仅适用于HTTP）以及能够以“ zoo”的不同技术工作（Mountebank有用于不同语言的库）。
基里尔·托尔卡切夫（Kirill Tolkachev）。 使用Spring Boot Test进行测试和哭泣
还有Java，微服务和JUnit5。Kirill是Java社区众所周知的Joker和JPoint会议的另一位发言人，他在Heisenbug上首次演讲。
该报告是去年
Spring Curse报告的修改版本，其中包含针对JUnit5和Spring Boot 2修改的示例。我们深入研究了与在组件/微服务测试中配置Spring Boot测试有关的各种实际问题。 例如，给我留下深刻印象的示例是在源代码树的正确位置使用空的
@SpringBootConfiguration StopConfiguration停止配置扫描过程，以及使用
@MockBean和
@SpyBean代替
@MockBean的可能性。 像Cyril和Evgeny Borisov的其他报告一样，在Spring框架的实际使用过程中可以重新使用这些材料。
安德烈·卡波夫（Andrey Karpov）。 静态分析仪可以做什么，程序员和测试人员不能做什么
静态代码分析是一件好事。 根据持续交付的规范，这应该是交付管道的第一阶段，过滤出具有可通过“读取”代码检测到的问题的代码。 静态分析之所以好，是因为它快速（比测试快得多）且便宜（不需要团队以编写测试的形式进行额外的工作：所有检查均已由分析仪的作者进行了编写）。
PVS-Studio项目的创始人之一（安德鲁·卡波夫（Andrey Karpov），Habr读者熟悉他的
博客 ）创建了一份报告，该报告举例说明了使用PVS-Studio在已知产品的代码分析中发现了哪些错误。 PVS Studio本身是一个多语言产品，它支持C，C ++，C＃，以及最近的Java。
在我看来，尽管上述示例很有趣，并且对它们进行静态分析的作用显而易见，但在我看来，Andrey的报告仍存在缺陷。
首先，该报告仅基于PVS-Studio产品的考虑（据发言人称，其平均价格为10,000美元）。 但是值得一提的是，实际上，在许多语言中，有许多已开发的OpenSource静态分析系统。 仅在Java中，免费的Checkstyle和SpotBugs（冻结的FindBugs项目的后继产品）以及IntelliJ IDEA分析器（可与IDE分开启动并收到报告）取得了长足的进步。
其次，谈到静态分析，在我看来，总是值得一提的是这种方法的基本局限性。 并非所有人都在大学里学习过算法理论，例如，熟悉“关机问题”。
最后，根本没有提出将静态分析引入现有代码库的问题，这仍然使许多人无法在项目上正常使用分析器。 例如，我们在一个大型的遗留项目上运行了分析器，发现了100,500个voring。 没有时间和精力立即修复它们，并且大规模更改代码中的某些内容将带来风险。 该怎么办，如何使静态分析作为质量门？ 在与Andrei的讨论区中讨论了此问题，但报告本身未考虑此问题。
总的来说，我祝安德烈和他的团队一切顺利。 他们的产品很有趣，在这个领域占据优势的想法非常大胆。
***
关于第一天和第二天的最后主题演讲，我可能什么也不会说：它们都是您只需要观看的版权展示。 谈论他们就像在重述文字，例如摇滚乐队的表演。
在一
年前的报告中
，我已经试图传达会议的总体气氛，并讨论了讨论区，午餐和聚会中正在发生的事情，因此我不再重复。
最后，我要感谢组织者举办的另一场精美的会议。 据我了解，对会议的兴趣略超出了预期，有人预订过多，甚至每个人都没有足够的纪念品。 但是可以肯定的是，每个人都有更重要的事情：有趣的报告，讨论空间，食物和饮料。 我期待着新的聚会！