Bird
Raised Fist0
PyTesttesting~8 mins

Deterministic tests in PyTest - Framework Patterns

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Framework Mode - Deterministic tests
Folder Structure
tests/
├── test_example.py
├── test_utils.py
├── data/
│   └── test_data.json
├── fixtures/
│   └── conftest.py
utils/
├── helpers.py
configs/
├── config.yaml
pytest.ini

Test Framework Layers
  • Tests: Actual test files inside tests/ folder, e.g., test_example.py. These contain test functions using pytest.
  • Fixtures: Setup and teardown code in tests/fixtures/conftest.py to prepare test environment and data.
  • Test Data: Static data files in tests/data/ used to provide consistent inputs for tests.
  • Utilities: Helper functions in utils/helpers.py to support tests without side effects.
  • Configuration: Settings like environment variables, browser options, and credentials stored in configs/config.yaml and pytest.ini.
Configuration Patterns
  • Environment Config: Use configs/config.yaml to define environments (dev, test, prod) with fixed URLs and credentials.
  • pytest.ini: Configure pytest options like markers and test paths to keep tests organized and consistent.
  • Fixtures for Setup: Use conftest.py fixtures to initialize resources deterministically before tests run.
  • Seed Data: Load fixed test data from JSON files to ensure tests always get the same inputs.
  • Avoid Randomness: Do not use random or time-dependent data unless seeded and controlled.
Test Reporting and CI/CD Integration
  • pytest Reports: Use built-in pytest reports with --junitxml=report.xml for CI systems.
  • CI Integration: Configure CI pipelines (GitHub Actions, Jenkins) to run tests on every commit ensuring deterministic results.
  • Fail Fast: Enable pytest options to stop on first failure to quickly detect flaky or non-deterministic tests.
  • Logs and Artifacts: Save logs and screenshots on failure to help diagnose non-deterministic behavior.
Best Practices for Deterministic Tests
  1. Fixed Test Data: Always use static or seeded data to avoid randomness.
  2. Isolate Tests: Each test should run independently without relying on others.
  3. Use Fixtures: Setup and teardown with fixtures to ensure consistent environment state.
  4. Avoid External Dependencies: Mock or stub external services to prevent variability.
  5. Control Time: Use time freezing or fixed timestamps if tests depend on time.
Self Check

Where would you add a new fixture that sets up a database connection with fixed test data for deterministic tests?

Key Result
Organize pytest tests with fixed data, fixtures, and configs to ensure deterministic, repeatable results.

Practice

(1/5)
1. What does it mean for a test to be deterministic in pytest?
easy
A. The test depends on external services to pass.
B. The test always produces the same result given the same inputs.
C. The test uses random data every time it runs.
D. The test runs faster than non-deterministic tests.

Solution

  1. Step 1: Understand the meaning of deterministic tests

    Deterministic tests produce consistent results every time they run with the same inputs.
  2. Step 2: Compare options with this definition

    Only The test always produces the same result given the same inputs. states that the test always produces the same result given the same inputs, matching the definition.
  3. Final Answer:

    The test always produces the same result given the same inputs. -> Option B
  4. Quick Check:

    Deterministic = Same result every time [OK]
Hint: Deterministic means repeatable results every run [OK]
Common Mistakes:
  • Confusing deterministic with fast tests
  • Thinking randomness is allowed in deterministic tests
  • Assuming external dependencies make tests deterministic
2. Which of the following is the correct way to fix randomness in a pytest test to make it deterministic?
easy
A. Use a fixed seed for the random number generator.
B. Remove all assertions from the test.
C. Run the test multiple times and average the results.
D. Use random data without controlling it.

Solution

  1. Step 1: Identify how to control randomness

    Setting a fixed seed for the random number generator ensures the same random values each run.
  2. Step 2: Evaluate options for fixing randomness

    Only Use a fixed seed for the random number generator. uses a fixed seed, which makes the test deterministic. Other options do not control randomness properly.
  3. Final Answer:

    Use a fixed seed for the random number generator. -> Option A
  4. Quick Check:

    Fixed seed = deterministic randomness [OK]
Hint: Fix random seed to control randomness [OK]
Common Mistakes:
  • Removing assertions does not fix randomness
  • Averaging results does not make test deterministic
  • Using uncontrolled random data causes flaky tests
3. Given this pytest test code, what will be the output when run twice?
import random

def test_random_number():
    random.seed(42)
    num = random.randint(1, 10)
    assert num == 2
medium
A. The test will pass both times because the seed fixes the random number.
B. The test will fail both times because 2 is not the generated number.
C. The test will pass the first time and fail the second time.
D. The test will fail the first time and pass the second time.

Solution

  1. Step 1: Understand the effect of setting random.seed(42)

    Setting the seed to 42 makes random.randint(1, 10) produce the same number every run.
  2. Step 2: Check the generated number and assertion

    With seed 42, random.randint(1, 10) returns 2, so the assertion num == 2 passes every time.
  3. Final Answer:

    The test will pass both times because the seed fixes the random number. -> Option A
  4. Quick Check:

    Seed 42 -> randint = 2 == 2 -> assert passes [OK]
Hint: Seed fixes random output to 2, so assertion num==2 passes consistently [OK]
Common Mistakes:
  • Thinking the test passes because of seed (but checks wrong number)
  • Assuming random changes every run despite seed
  • Not verifying that seed(42) produces 2 for randint(1,10)
4. This pytest test sometimes fails randomly. What is the main issue?
import random

def test_random_fail():
    num = random.randint(1, 10)
    assert num == 5
medium
A. The test function name is invalid.
B. The assertion syntax is incorrect.
C. The test does not fix the random seed, causing non-deterministic results.
D. The random module is not imported.

Solution

  1. Step 1: Identify randomness control in the test

    The test uses random.randint without setting a seed, so output varies each run.
  2. Step 2: Understand why this causes test failure

    Because the number is random, the assertion num == 5 sometimes fails, making the test flaky.
  3. Final Answer:

    The test does not fix the random seed, causing non-deterministic results. -> Option C
  4. Quick Check:

    No seed -> random output varies -> flaky test [OK]
Hint: No seed means random output, causing flaky tests [OK]
Common Mistakes:
  • Thinking assertion syntax is wrong
  • Assuming test name affects determinism
  • Ignoring that random module is correctly imported
5. You want to write a deterministic pytest test that checks if a function returns the current date. Which approach ensures determinism?
hard
A. Call the function without any changes and assert the result.
B. Run the test only once to avoid variability.
C. Use the actual current date and accept test failures on different days.
D. Mock the current date to a fixed value during the test.

Solution

  1. Step 1: Understand why current date causes non-determinism

    The current date changes every day, so tests using it without control will fail on different days.
  2. Step 2: Identify how to fix the date for deterministic testing

    Mocking the current date to a fixed value ensures the test always sees the same date and passes consistently.
  3. Final Answer:

    Mock the current date to a fixed value during the test. -> Option D
  4. Quick Check:

    Mock date -> fixed input -> deterministic test [OK]
Hint: Mock changing data like dates for stable tests [OK]
Common Mistakes:
  • Using real current date causes flaky tests
  • Ignoring mocking leads to non-deterministic results
  • Running test once does not guarantee determinism