他们说，加快测试速度。
现在，自从我们重写了旧的，未切割的，长期且不稳定的功能测试，并切换到与组件无关的快速测试以来，已经过去了半年。 因此，是时候分享了:)
对于那些不知道的人，
组件测试是与全局环境完全隔离的测试，可让您检查单元测试无法涵盖的某些情况。
六个月前，鉴于该代码已经经过长时间的全面测试，而发布该功能通常要花费一个多小时，但是master分支无法实现绿色构建，然后出现了一个问题：如何生存？
的确，在这种情况下，伤害测试远不止于事，但摆脱它们并为测试“评分”远非最佳选择：)然后，由团队负责人组建了一个小型微型团队：
- 蒂姆利达
- 后端开发人员
- 质量检查工程师
- 管理员
在迅速合作之后，我们分了任务，其中一个任务是建立一个用于编写组件测试的环境。 因此，我的旅程开始了。
在开发开始时，我们进行了140多个功能测试，这些测试在不同的环境（前端，移动，后端）中的多个线程中运行，大约需要5到7分钟的时间； 还常常必须重新启动它们才能实现绿色构建。 这些测试不再因为新的书面代码而下降，而是由于环境中的问题，即API没有响应的地方，测试微服务下降的地方，等等。 这停止了整个部门的工作，因为组装几乎每5-10分钟启动一次：有人重新组装，有人推送了新代码...
在一周的第一周之后，我们得出的结论是，我们将“弄湿”我们的API和第三方服务，这将为我们提供一个完全隔离的测试环境。 但是问题出现了：写自己的东西或...于是，在这个“或”上，一切都以我遇到的方式进行了短暂的搜索而告终-以Mock服务器“ http-api-mock”的形式花费了很少的时间。
http-api-mock是使用Go语言编写的轻量级且无需安装的模拟服务器，并提供了完善的文档。
经过数百次尝试启动以及通常深入研究mok的主题之后，我仍然设法重写了1个功能测试，该功能测试在网站上创建了一个新广告，并且经过所有地狱的努力之后，我确信页面上的标题与对象主体中的标题相对应。
想象一下赚到了！ 重写后的测试结果比以前的测试快3倍，因为在这里我们没有检查创建，审核，而是立即从Mock返回所需的广告对象并赢得了它。 这次小小的胜利成为进一步发展该主题的良好动力，因此，又过了一周，我们在代码接收中有了一个名为“ component”的新套件，该套件已经具有用于与我们的Mock服务器一起工作的基础帮助程序类，并在那时启动了我在沙盒中。
基本帮助程序类可以在我们的模拟服务器的config目录中以json文件的形式创建广告，并通过id给出所需的广告，等等。 几乎是一个API。
剩下的魔力还在等着我们-现在只剩下用竹子制定装配计划了。 这样我们的测试就可以通过CI＆CD了。
管理员通过在docker中启动所有这些测试的设置为我们提供了帮助，该设置使我们可以为每个构建使用Mock服务器提升容器，并在完全隔离的环境中运行测试，而无需将代码部署到任何测试后端，这也无法不要加快我们的测试。
为了使所有这些魔术发挥作用，我们必须添加具有新API地址和外部服务的新配置文件，并提出mysql数据库的副本，并在启动模拟服务器时在构建计划中创建新任务。
现在，对于我们的代码，有了一个全新的API，无论遇到任何环境问题，它都能为我们提供所需的东西。
经过了一段时间，测试被重写，并且140个功能测试变成了103个组件测试，这些测试在约30秒内并行运行。
的优点
很敏捷 。 由于它们完全独立于测试环境，因此它们不必花费太多数据。
稳定 。 测试不必担心我们的API或任何其他服务是否落在那儿，因此我们始终确保结果会到来。
容易写 。 实际上，在重写过程中，很多决定是通过将代码从旧的功能测试复制到新的组件测试，并在Mock服务器中为其准备端点。
的缺点
支持 。 现在，每个对API中特定终结点的返回响应进行了更改的开发人员，都将使用模拟服务器的配置进入存储库并在此处更正答案。
一堆文件 。 他们决定将配置文件中的数据以文件的形式存储，也就是说，端点的每个答案都以文件形式存在，并且可能会丢失在某个地方。
结果：
测验那是：140+次功能测试= 5-7分钟。
现在：103个组件测试=〜30秒。
建造稳定性那是：每三分之二的组装由于任何问题而倒下。
它变成了：只有当开发人员破坏某种方法的逻辑时，它才跌落。
在将来的计划中，我们必须重写验收（gui）测试-还必须在容器内运行它们，并将它们与环境的其余部分隔离。