Dav*_*vid 15 testing continuous-integration unit-testing docker
我是Docker的新手,正在阅读Docker.这是一种在自包含且可重现的标准化配置中测试系统的好方法(正确完成时).
但是,在我读过的所有内容中,似乎没有过多强调如何使用docker容器进行测试.docker用于"包含"基础架构和应用程序(代码),以便于测试(以及部署).但有时测试代码库很大,也不是那么简单.一个可以有一个用于API测试的测试代码库,另一个用于UI,等等.
什么是或应该(在某些时候确定)测试应用程序/基础架构的docker容器/部署的标准做法?应该:
我能想到的唯一原因使得dockerizing测试可能有用,它是一个单独的容器,包含您需要的所有测试和匹配的测试基础架构(所有测试平台/语言依赖项),因此可以在任何地方部署和运行测试匹配的应用代码容器.从/根据需要保存必须设置测试基础设施.但似乎似乎没有博客关于这种针对码头化测试的事情.
我更喜欢你的选项(3),即在生产可部署工件(docker 镜像)中包含测试代码
\n\n引用我参加的GTAC 2015的Alister Scott的话:
\n\n\n\n\n不要害怕向您的应用程序添加可测试性特定功能,而这些功能不服务于功能目的。我最近不得不在我的车上安装新轮胎,并意识到很多轮胎都具有称为胎面指示器的可测试性功能。这些不\xe2\x80\x99t服务于功能目的
\n
对于集成和 e2e 测试,即需要使用超过 1 个 docker 镜像的测试,我更喜欢CI 工具,它通过docker-compose和用于这些测试的单独 git 存储库,协调创建所需的所有容器。更大的测试。同样,使用的 docker 镜像应该与生产环境完全相同,不同之处在于使测试指向测试数据和/或登台服务的配置(例如环境变量)。
\n我认为您不会将测试本身作为运行测试的进程进行 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)
| 归档时间: |
|
| 查看次数: |
3074 次 |
| 最近记录: |