GitLab CI/CD中拉取的Docker镜像无法识别Django测试用例

我之前帮朋友排查过几乎一模一样的问题，结合你的配置和症状，给你整理几个关键的排查方向，一步步来定位问题：

1. 先确认容器里有没有测试文件 #

你的测试服务用的命令是bash -c "python /app/src/manage.py test"，首先得搞清楚容器里的/app/src目录下到底有没有测试文件（比如tests文件夹或者test_开头的py文件）。

• 可以在测试阶段的脚本里加一步验证：在docker-compose run test之前，先跑docker-compose run test ls -la /app/src，看看输出里有没有你的测试文件。
• 另外回忆下本地跑测试的工作目录，是不是本地在src文件夹里直接跑python manage.py test，而容器里用的绝对路径有没有问题？比如测试文件是不是在/app/src/tests下，Django能不能找到？

2. 数据库可能还没准备好就跑测试了 #

你的test服务依赖postgres，但docker-compose的depends_on只是保证postgres容器先启动，不代表数据库服务已经完全就绪可以连接。很多时候测试跑起来的时候，数据库还在初始化，导致测试用例因为连不上数据库被直接跳过，就会显示Ran 0 tests。

• 解决办法是在测试命令前加个等待数据库就绪的脚本，比如改成：

  bash -c "until pg_isready -h postgres -U solo; do sleep 1; done; python /app/src/manage.py test"
  

  注意要在你的镜像里装postgresql-client才能用pg_isready，如果是Debian/Ubuntu基础镜像，就在Dockerfile里加apt-get install -y postgresql-client；如果是Alpine镜像，就加apk add postgresql-client。

3. 检查镜像构建时有没有把测试文件排除 #

你的build阶段是构建镜像然后push到GitLab仓库，要确认构建出来的镜像里确实包含了测试文件。

• 先检查.dockerignore文件，有没有不小心把tests目录或者test_*.py文件忽略了？这是非常常见的坑！
• 也可以在build阶段之后临时跑个容器验证：docker run --rm $CI_REGISTRY:$CI_COMMIT_REF_NAME ls -la /app/src，看看测试文件是不是在里面。

4. 让测试命令输出更详细的日志 #

默认的manage.py test如果没找到测试用例只会显示一句Ran 0 tests，根本看不到哪里出问题。可以加-v 2参数开启详细日志：

python /app/src/manage.py test -v 2

这样能看到Django在哪些目录搜索测试用例，有没有发现测试文件，有没有报错导致测试被跳过，信息会详细很多。

5. 确认CI拉取的是最新构建的镜像 #

你的测试阶段用docker-compose pull test拉取镜像，要确保拉取的是build阶段刚构建好的那个版本（也就是$CI_COMMIT_REF_NAME标签的镜像）。可以在测试脚本里加docker images命令，看看镜像的标签和构建时间，是不是最新的那个，避免拉到旧镜像导致测试文件缺失。

6. 对比本地和CI的环境变量差异 #

本地跑测试的环境变量和CI容器里的环境变量可能不一样，比如Django的DEBUG设置、数据库配置等，这些都可能影响测试用例的加载。可以在测试命令前先输出所有环境变量：

bash -c "printenv; python /app/src/manage.py test"

看看有没有什么环境变量导致测试用例不被识别。

内容的提问来源于stack exchange，提问作者Alexander Lekontsev