Beyond using prebuilt images, QA engineers often need custom containers that bundle specific test tools, mock servers or data initialisation logic. Dockerising these dependencies makes it easy to spin them up consistently across machines and pipelines.
Creating Images for Test Services and Mocks
A Dockerfile describes how to build an image, including which base image to use, what packages to install and which commands to run on startup. For example, you might create a small Node-based mock API service to simulate third-party integrations during tests.
# Example: Dockerfile for a simple mock API
FROM node:20-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["npm", "run", "start:mock"]qa-mock-api:latest) and document how to run them so the whole team can reuse them.Once you have images for your database, mocks and other dependencies, you can orchestrate them together with docker-compose.
Common Mistakes
Mistake 1 — Embedding test data in application code only
This makes it hard to reuse.
❌ Wrong: Hard-coding mock responses in many separate test scripts.
✅ Correct: Centralise mocks into dedicated services that tests can call.
Mistake 2 — Building huge, slow images for simple services
This slows feedback.
❌ Wrong: Using heavy base images and installing unnecessary tools.
✅ Correct: Use slim or alpine images and include only what is needed for the test service.