DEV Community
·
我反对在测试中使用容器
内容提要
作者在使用Testcontainers三年后认为其设置和维护复杂，难以排查问题，且服务测试只能覆盖简单路径，无法真实反映云服务表现。建议在单元测试中模拟外部依赖，并创建快速部署环境，以替代容器服务测试。
关键要点
-
作者使用Testcontainers三年后认为其设置和维护复杂，难以排查问题。
-
服务测试只能覆盖简单路径，无法真实反映云服务表现。
-
建议在单元测试中模拟外部依赖，并创建快速部署环境。
-
容器服务测试的维护成本高，且排查问题困难。
-
容器无法真实模拟云服务的表现，例如DynamoDB的最终一致性。
-
建议开发者创建一个或多个快速部署环境，以便快速测试和验证。
-
作者希望读者在决定添加基于容器的服务测试前仔细考虑。
延伸解读
容器测试的复杂性
作者指出，使用Testcontainers进行服务测试的设置和维护非常复杂，尤其是在多操作系统环境中。这意味着开发者在选择容器测试时需要考虑额外的时间和精力投入，可能会影响项目的进度和效率。
云服务表现的局限性
文章提到，容器无法真实模拟云服务的表现，例如DynamoDB的最终一致性。这提醒开发者在进行服务测试时，需谨慎评估测试结果的可靠性，以免对产品上线后的表现产生误判。
替代方案的有效性
作者建议在单元测试中模拟外部依赖，并创建快速部署环境。这种方法不仅可以减少维护成本，还能提高测试的灵活性和效率，值得开发团队考虑作为容器测试的替代方案。
延伸问答
为什么作者反对在测试中使用容器？
作者认为容器的设置和维护复杂，难以排查问题，且服务测试只能覆盖简单路径，无法真实反映云服务表现。
使用Testcontainers的主要问题是什么？
主要问题包括需要大量的设置和维护，排查问题困难，以及测试只能覆盖简单路径。
作者建议如何替代容器服务测试？
作者建议在单元测试中模拟外部依赖，并创建一个或多个快速部署环境，以便快速测试和验证。
容器测试无法真实模拟云服务表现的原因是什么？
因为容器无法反映云服务的最终一致性等特性，例如DynamoDB的表现。
作者对服务测试的看法是什么？
作者认为服务测试的维护成本高，且往往只能覆盖与端到端测试相同的简单路径，缺乏实际价值。
在进行服务测试时，作者遇到了哪些具体问题？
作者遇到的问题包括镜像下载困难、容器实例化问题以及排查日志的复杂性。
