What is the difference between a Docker image and a container, and why use Docker for testing?

Image vs container

An image is a read-only, layered filesystem plus metadata (default command, environment variables, exposed ports). You build it from a Dockerfile; each instruction such as RUN or COPY creates a layer, and layers are cached and shared between images. Images are identified by a tag (postgres:16) and, more precisely, by an immutable digest.

A container is a running instance of an image. Docker adds a thin writable layer on top and runs the process in isolated namespaces with its own filesystem view, network and process tree. You can run many containers from one image, and when you remove a container its writable layer is gone. That disposability is exactly what testing wants.

A useful analogy: the image is the class, the container is the object.

docker pull postgres:16
docker run -d --name testdb -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:16
docker ps
docker logs testdb
docker rm -f testdb   # gone, along with its data

Containers share the host’s kernel, so they start in seconds and use far less memory than virtual machines, which each run a full guest OS.

Why testers care

• Reproducible environments. The test runner image pins the language runtime, browser versions and tools. “Works on my machine” turns into “works in this image”, and CI uses the same image.
• Disposable dependencies. Start a fresh database, message broker or mock server for a test run and throw it away afterwards. No shared, polluted test databases.
• Browsers in containers. Official Selenium images (selenium/standalone-chrome) and the Playwright Docker image bundle browsers and their OS dependencies, so CI agents don’t need them installed.
• Isolation for parallelism. Each parallel job can have its own stack without port or data collisions.
• Testing what ships. If production runs a container image, testing that same image removes a class of “environment difference” bugs.

Limits to keep in mind

• Docker does not make tests deterministic by itself; data and timing issues remain.
• Containers on a laptop are not production: resource limits, networking and scale differ.
• Images need maintenance: pinned versions get stale and accumulate vulnerabilities.

What interviewers look for

• A precise image vs container distinction (template vs running instance, layers, writable layer).
• Concrete testing benefits: reproducibility, disposable dependencies, browsers in containers.
• Awareness that containers are lighter than VMs because they share the kernel.