Docker containers for test execution in Selenium Python - Build an Automation Script

Run Selenium test inside a Docker container

Preconditions (3)

Step 1: Create a Dockerfile that installs Python, Selenium, and a browser driver

Step 2: Build the Docker image from the Dockerfile

Step 3: Run the Docker container with the test script mounted inside

Step 4: Execute the Selenium test script inside the container

Step 5: Observe the test execution and results

✅ Expected Result: The Selenium test runs successfully inside the Docker container and outputs the test result (pass/fail) to the console

Automation Requirements - Selenium with Python

Assertions Needed:

Verify the page title is as expected

Verify a specific element is present on the page

Best Practices:

Use explicit waits instead of sleep

Use Page Object Model for maintainability

Use Docker volumes to mount test scripts

Use headless browser mode for container execution

Automated Solution

Selenium Python

import unittest
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class TestGoogleSearch(unittest.TestCase):
    def setUp(self):
        chrome_options = Options()
        chrome_options.add_argument('--headless')
        chrome_options.add_argument('--no-sandbox')
        chrome_options.add_argument('--disable-dev-shm-usage')
        self.driver = webdriver.Chrome(service=Service('/usr/bin/chromedriver'), options=chrome_options)
        self.wait = WebDriverWait(self.driver, 10)

    def test_google_title_and_search_box(self):
        self.driver.get('https://www.google.com')
        # Assert page title
        self.assertIn('Google', self.driver.title)
        # Wait for search box presence
        search_box = self.wait.until(EC.presence_of_element_located((By.NAME, 'q')))
        self.assertTrue(search_box.is_displayed())

    def tearDown(self):
        self.driver.quit()

if __name__ == '__main__':
    unittest.main()

# Dockerfile content (to be created separately):
# FROM python:3.12-slim
# RUN apt-get update && apt-get install -y wget gnupg2 \
#     && wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add - \
#     && echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list \
#     && apt-get update && apt-get install -y google-chrome-stable \
#     && pip install selenium
# RUN wget https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_linux64.zip \
#     && unzip chromedriver_linux64.zip \
#     && mv chromedriver /usr/bin/chromedriver \
#     && chmod +x /usr/bin/chromedriver
# COPY test_script.py /tests/test_script.py
# WORKDIR /tests
# CMD ["python", "test_script.py"]

This test script uses Python's unittest framework with Selenium WebDriver.

In setUp, we configure Chrome to run in headless mode, which is important for running inside Docker containers without a display.

The test navigates to Google, checks the page title contains 'Google', and waits explicitly for the search box element to appear, then asserts it is visible.

The tearDown method closes the browser after the test.

The Dockerfile installs Chrome, ChromeDriver, and Selenium, then copies the test script inside the container and runs it.

This setup allows running the Selenium test fully inside a Docker container, ensuring consistent environment and easy test execution.

Common Mistakes - 4 Pitfalls

Using time.sleep() instead of explicit waits

{'mistake': 'Not running browser in headless mode inside Docker', 'why_bad': 'Docker containers usually have no display, so tests fail if browser tries to open GUI.', 'correct_approach': "Use headless browser options like '--headless' for Chrome."}

Hardcoding absolute paths for ChromeDriver

Not closing the browser after test

Bonus Challenge

Now add data-driven testing with 3 different URLs to verify their page titles inside the Docker container.

Show Hint

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