Docker containers for test execution in Selenium Python - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a Docker container in the context of test execution?

A Docker container is a lightweight, standalone package that includes everything needed to run a test, such as code, runtime, system tools, and libraries. It ensures tests run the same way on any machine.

beginner

Why use Docker containers for Selenium test execution?

Docker containers provide a consistent environment for Selenium tests, avoid "it works on my machine" issues, simplify setup, and allow easy scaling and parallel test runs.

intermediate

How do you run a Selenium test inside a Docker container?

You create a Docker image with Selenium and browser drivers installed, then run the container to execute your test scripts inside this isolated environment.

intermediate

What is the role of Docker Compose in test execution with containers?

Docker Compose helps define and run multi-container Selenium test environments, like a Selenium Grid with hub and nodes, using a simple YAML file.

intermediate

Name one best practice when using Docker containers for test execution.

Keep containers lightweight by only including necessary dependencies, and use volume mounts to access test code without rebuilding images each time.

What is a key benefit of running Selenium tests inside Docker containers?

A Tests run in a consistent environment everywhere

B Tests run faster than native execution always

C No need to write test scripts

D Docker automatically fixes test failures

Docker containers ensure the same environment for tests, avoiding differences between machines.

Which tool helps manage multiple Docker containers for Selenium Grid?

A Git

B Postman

C Jenkins

D Docker Compose

Docker Compose defines and runs multi-container setups like Selenium Grid.

What should you include inside a Docker image for Selenium test execution?

A No dependencies, just the browser

B Selenium server, browser drivers, and test dependencies

C The entire operating system ISO

D Only the test scripts

The image must have Selenium server, browser drivers, and any libraries needed to run tests.

How can you avoid rebuilding Docker images every time you change test code?

A Use volume mounts to share test code with the container

B Rebuild images for every test run

C Copy code manually inside container each time

D Run tests outside Docker

Volume mounts let containers access updated test code without rebuilding images.

What is a common use case for Docker containers in test automation?

A Writing test scripts automatically

B Replacing manual testing completely

C Running browser tests in isolated, repeatable environments

D Hosting production web servers

Docker containers help run automated browser tests reliably and consistently.

Explain how Docker containers improve Selenium test execution.

Think about how running tests on different machines can cause problems.

Describe the steps to set up a Selenium test using Docker containers.

Consider what you need inside the container and how to run tests.

Practice

1. What is the main benefit of using Docker containers for Selenium test execution?

easy

A. They replace the need for writing test scripts

B. They provide a clean, consistent environment for tests to run

C. They automatically fix test failures

D. They make tests run faster on any machine

Solution

1. Step 1: Understand Docker container purpose

   Docker containers isolate the environment so tests run the same everywhere.

2. Step 2: Compare options

   Only They provide a clean, consistent environment for tests to run correctly describes this benefit; others are incorrect or unrelated.

3. Final Answer:

   They provide a clean, consistent environment for tests to run -> Option B

4. Quick Check:

   Docker containers = consistent test environment [OK]

Hint: Docker isolates environment to avoid setup issues [OK]

Common Mistakes:

• Thinking Docker speeds up tests automatically
• Believing Docker fixes test code errors
• Confusing Docker with test script writing

2. Which Python Selenium WebDriver URL should you use to connect to a Selenium server running inside a Docker container?

easy

A. "http://localhost:4444/wd/hub"

B. "http://127.0.0.1:8080"

C. "http://docker:5555"

D. "http://0.0.0.0:80"

Solution

1. Step 1: Identify default Selenium server URL in Docker

   The Selenium server in Docker usually listens on port 4444 at localhost.

2. Step 2: Match URL options

   Only "http://localhost:4444/wd/hub" matches the standard Selenium Docker URL format.

3. Final Answer:

   "http://localhost:4444/wd/hub" -> Option A

4. Quick Check:

   Default Selenium Docker URL = localhost:4444/wd/hub [OK]

Hint: Selenium Docker server default port is 4444 [OK]

Common Mistakes:

• Using wrong port numbers
• Using IPs other than localhost
• Missing the /wd/hub path

3. Given this Python code snippet connecting to a Selenium Docker container, what will be the output if the container is not running?

from selenium import webdriver
from selenium.common.exceptions import WebDriverException

try:
    driver = webdriver.Remote(
        command_executor='http://localhost:4444/wd/hub',
        options=webdriver.ChromeOptions()
    )
    print("Connected")
except WebDriverException:
    print("Connection failed")

medium

A. Connection failed

B. Connected

C. SyntaxError

D. TimeoutError

Solution

1. Step 1: Understand connection attempt

   The code tries to connect to Selenium server at localhost:4444.

2. Step 2: Consider container not running

   If the container is down, connection fails and WebDriverException is raised, triggering except block.

3. Final Answer:

   Connection failed -> Option A

4. Quick Check:

   Container down causes WebDriverException = "Connection failed" [OK]

Hint: If container off, connection throws WebDriverException [OK]

Common Mistakes:

• Expecting 'Connected' even if container is off
• Confusing exception types
• Thinking code has syntax errors

4. You wrote this Docker command to run Selenium server:

docker run -d -p 4444:4444 selenium/standalone-chrome

But your Selenium Python tests fail to connect. What is the most likely issue?

medium

A. You used the wrong port mapping in Docker command

B. You forgot to install Selenium Python package

C. Docker container is not running or crashed

D. Your test code uses an incorrect WebDriver import

Solution

1. Step 1: Check Docker container status

   If tests can't connect, first check if container is running or crashed.

2. Step 2: Evaluate other options

   The other options are less likely because the Docker command uses correct port mapping and Selenium package or imports cause different errors.

3. Final Answer:

   Docker container is not running or crashed -> Option C

4. Quick Check:

   Connection fails if container stopped = Docker container is not running or crashed [OK]

Hint: Check container running status first when connection fails [OK]

Common Mistakes:

• Assuming code import errors cause connection failure
• Ignoring container crash possibility
• Confusing port mapping syntax

5. You want to run multiple Selenium Python tests in parallel using Docker containers. Which approach best ensures isolated, reliable test runs?

hard

A. Run tests locally without Docker to avoid container overhead

B. Run all tests in a single container sharing the same browser session

C. Use Docker but share the same Selenium server URL for all tests

D. Run one Docker container per test with unique ports and clean state

Solution

1. Step 1: Understand parallel test isolation

   Running one container per test ensures each test has a clean browser and no interference.

2. Step 2: Evaluate other options

   Sharing containers or sessions risks test interference and flaky results; running locally loses Docker benefits.

3. Final Answer:

   Run one Docker container per test with unique ports and clean state -> Option D

4. Quick Check:

   Parallel tests need isolated containers = Run one Docker container per test with unique ports and clean state [OK]

Hint: Use separate containers per test for isolation [OK]

Common Mistakes:

• Sharing one container causing test conflicts
• Ignoring container cleanup between tests
• Running tests locally losing environment consistency