像往常一样对Docker容器或dockerize测试运行测试?

Dav*_*vid 15 testing continuous-integration unit-testing docker

我是Docker的新手,正在阅读Docker.这是一种在自包含且可重现的标准化配置中测试系统的好方法(正确完成时).

但是,在我读过的所有内容中,似乎没有过多强调如何使用docker容器进行测试.docker用于"包含"基础架构和应用程序(代码),以便于测试(以及部署).但有时测试代码库很大,也不是那么简单.一个可以有一个用于API测试的测试代码库,另一个用于UI,等等.

什么是或应该(在某些时候确定)测试应用程序/基础架构的docker容器/部署的标准做法?应该:

  • 测试代码以旧的传统方式部署,作为文件存储库,您从某处运行,然后在Jenkins服务器/从服务器或一个本地主机上运行dev/QA测试/调试,测试针对docker容器中的应用程序?
  • 将整个测试代码库作为自包含容器进行dockerize,然后使用该容器针对具有应用程序代码/系统基础结构的其他容器启动/执行测试?
  • 将测试作为各个docker容器本身的一部分进行组合,以便在需要时运行.但我认为这最适合仅与容纳匹配应用程序代码的容器配对的单元测试.集成,UI,系统级测试与系统中的app模块相关联.

我能想到的唯一原因使得dockerizing测试可能有用,它是一个单独的容器,包含您需要的所有测试和匹配的测试基础架构(所有测试平台/语言依赖项),因此可以在任何地方部署和运行测试匹配的应用代码容器.从/根据需要保存必须设置测试基础设施.但似乎似乎没有博客关于这种针对码头化测试的事情.

Leo*_*cci 5

我更喜欢你的选项(3),即在生产可部署工件(docker 镜像)中包含测试代码

\n\n

引用我参加的GTAC 2015的Alister Scott的话:

\n\n
\n

不要害怕向您的应用程序添加可测试性特定功能,而这些功能不服务于功能目的。我最近不得不在我的车上安装新轮胎,并意识到很多轮胎都具有称为胎面指示器的可测试性功能。这些不\xe2\x80\x99t服务于功能目的

\n
\n\n

对于集成和 e2e 测试,即需要使用超过 1 个 docker 镜像的测试,我更喜欢CI 工具,它通过docker-compose和用于这些测试的单独 git 存储库,协调创建所需的所有容器。更大的测试。同样,使用的 docker 镜像应该与生产环境完全相同,不同之处在于使测试指向测试数据和/或登台服务的配置(例如环境变量)。

\n


d3m*_*ing 2

我认为您不会将测试本身作为运行测试的进程进行 dockerize。

例如,如果您需要使用 phpunit 在 php 中运行单元测试,您可以对phpunit进行 dockerize并使用它来针对您的代码运行测试,对于您使用的任何其他测试框架(即 testng、junit...等)也类似。

下面是我用来封装 Java 测试项目的 Java/Maven/TestNG 的 Dockerfile 示例,其中包括一些 selenium 测试:

FROM maven:3-jdk-8

# Selectively add stuff we need
COPY pom.xml /usr/src/testng/

# Get a clean build immediately after and 'go-offline' to improve subsequent builds
RUN cd /usr/src/testng && mvn dependency:go-offline
COPY src /usr/src/testng/src
WORKDIR /usr/src/testng/

# Additional support files that's needed but not for the build
COPY supportfiles /usr/src/testng/supportfiles

CMD [ "mvn test" ]
Run Code Online (Sandbox Code Playgroud)