Docker containers for test execution in Selenium Python - Framework Patterns

Framework Mode - Docker containers for test execution

Folder Structure

selenium-python-docker/
├── tests/
│   ├── test_login.py
│   └── test_search.py
├── pages/
│   ├── login_page.py
│   └── search_page.py
├── utils/
│   ├── driver_factory.py
│   └── helpers.py
├── config/
│   ├── config.yaml
│   └── docker-compose.yml
├── Dockerfile
├── requirements.txt
└── README.md
    

Test Framework Layers

• Driver Layer: utils/driver_factory.py creates Selenium WebDriver instances inside Docker containers.
• Page Objects: pages/ contains page classes representing UI elements and actions.
• Tests: tests/ holds test scripts using pytest to run tests against pages.
• Utilities: utils/ has helper functions and driver setup logic.
• Configuration: config/config.yaml stores environment and browser settings; config/docker-compose.yml defines container setup.
• Docker Setup: Dockerfile builds the test environment image with Python, Selenium, and dependencies.

Configuration Patterns

Use config/config.yaml to define environment variables like URLs, browser types, and timeouts. This file is read by tests to adapt behavior.

config/docker-compose.yml configures services such as Selenium Grid or standalone browser containers (e.g., Chrome) and the test runner container.

Example snippet from config.yaml:

url: "https://example.com"
browser: "chrome"
timeout: 10
    

Example snippet from docker-compose.yml:

version: '3'
services:
  selenium-hub:
    image: selenium/hub:4.10.0-20230613
    ports:
      - "4444:4444"
  chrome:
    image: selenium/node-chrome:4.10.0-20230613
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
  tests:
    build: .
    depends_on:
      - selenium-hub
    environment:
      - BASE_URL=https://example.com
    command: pytest tests/
    

Test Reporting and CI/CD Integration

Use pytest plugins like pytest-html or pytest-junitxml to generate readable test reports inside the Docker container.

Reports are saved to mounted volumes so CI/CD pipelines can access them after test runs.

Integrate Docker test execution in CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI) by running docker-compose up --abort-on-container-exit to execute tests in containers.

Fail the pipeline if tests fail by checking container exit codes.

Best Practices

• Isolate Tests: Run tests in clean Docker containers to avoid environment conflicts.
• Use Selenium Grid: Use Selenium Hub and browser nodes for scalable parallel test execution.
• Keep Config Separate: Store environment and browser settings outside code in config files.
• Mount Volumes: Share test reports and logs between containers and host for easy access.
• Automate with CI/CD: Integrate Docker test runs into pipelines for consistent automated testing.

Self Check

Where in this folder structure would you add a new page object for the "User Profile" page?

Key Result

Use Docker containers to run Selenium Python tests in isolated, consistent environments with Selenium Grid for scalable browser management.

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