【问题标题】:Automated integration tests as part of Azure DevOps CD/CI作为 Azure DevOps CD/CI 一部分的自动化集成测试
【发布时间】:2020-09-22 13:06:46
【问题描述】:

基本的 Java CRUD 应用程序。没什么疯狂的。我们希望相应地测试数据层(因此我们依赖于数据库)。

该项目基于 maven,因此管道会运行构建/运行单元测试,然后相应地删除工件。

我的问题是:使用 Azure Pipelines 处理此问题的最佳做法是什么?我们是否应该运行一个内存数据库,一旦测试完成,我们就可以创建和销毁(所以基本上保持管道不变,并将其作为已经运行的 maven 测试的一部分处理)?这将使我们能够控制我们开始使用的数据并为所有测试创建适当的基线。

在推送到我们每次重建的 docker 容器后,在发布管道中执行此操作会更好吗?

什么是 Azure DevOps(甚至是一般的 DevOps)的“最佳实践”?

【问题讨论】:

  • 您可能想查看抽象 Docker 的 Testcontainers 并允许您针对要部署的内容进行测试。
  • 您可以尝试使用 azure 数据库服务器并在测试代码中设置连接字符串。或者,您可以创建一个自托管代理并在本地代理机器上设置数据库服务器。两者都将允许您的测试代码访问数据服务器。

标签: java azure azure-devops azure-pipelines


【解决方案1】:

我认为您应该运行 Mock 对象以便运行测试而不是使用真正的数据库。您还可以将测试封装在事务中,并在测试运行后强制它们失败并回滚数据库。

【讨论】:

  • 使用模拟对象的唯一问题(从我的角度来看,我可能错了)是它没有提供涉及项目和数据库的真正集成测试。这可能无关紧要,但我不确定这是否会被视为最佳做法。
【解决方案2】:

由于测试不依赖于环境的物理部署,因此我会在您的管道中尽可能将测试提前到 CI 阶段(Azure DevOps 构建阶段),因此满足 DevOps 主体以“快速失败” ”。

这还有一个优点,即测试也可以在拉取请求检查期间轻松运行。

在针对真实数据库或内存运行集成测试之间需要权衡取舍。真实的数据库可能会让您更有信心,但内存数据库可能会产生更可靠的测试套件。

针对已部署应用程序运行的功能/验收/黑盒测试当然应该放在管道的发布阶段。

祝你好运!希望这会有所帮助。

【讨论】:

    猜你喜欢
    • 2023-03-28
    • 1970-01-01
    • 2023-03-16
    • 1970-01-01
    • 2019-10-04
    • 1970-01-01
    • 1970-01-01
    • 2021-01-15
    • 2020-05-12
    相关资源
    最近更新 更多