Beyond the Basics: Preparing for Pytest Interview Questions in 2026

1. Why Pytest? The Framework for Modern Engineering

Pytest is an open-source Python framework designed for simplicity and scalability. While it’s the gold standard for Unit and Functional testing, its true power lies in handling complex, data-heavy environments like ETL, AI/ML, and Cloud APIs.

We use Pytest because it simplifies the testing process significantly:

• Minimal boilerplate: Write tests instantly with standard assert statements—perfect for rapid AI/ML experimentation.
• Automatic test discovery: It automatically finds and runs test files and functions, so you don’t need to manually register them.
• Powerful Fixtures: Manage expensive ETL resources (like Spark sessions or DB connections) with efficient setup/teardown logic.
• Smart Categorization: Use Markers to separate “Fast” unit tests from “Heavy” Big Data validation runs.
• Detailed reporting: Provides detailed failure reports, showing exactly where a data mismatch occurred in your pipeline or API response.

2. What is a Test Fixture in Pytest?

A test fixture is a function that sets up a reliable, repeatable environment for your tests. It handles the “heavy lifting” — like connecting to a database or initializing an AI model — so your test functions stay clean and focused.

Key Benefits:

• Setup: Prepares resources (e.g., creating a temporary file).
• Teardown: Cleans up after the test (e.g., closing a connection), ensuring no “side effects” linger.
• Independence: Each test gets a fresh, isolated state.

import pytest
import os
import tempfile

@pytest.fixture
def temp_config_file():
    # 1. Setup: Create a temporary file
    fd, path = tempfile.mkstemp(suffix='.ini')
    with os.fdopen(fd, 'w') as tmp:
        tmp.write("[settings]\ndatabase = 'my_db'\n")

    # 2. Provide the resource to the test
    yield path

    # 3. Teardown: Remove the file after the test finishes
    os.remove(path)

def test_read_database_setting(temp_config_file):
    # The fixture path is automatically passed as an argument
    with open(temp_config_file, 'r') as f:
        content = f.read()
    assert "database = 'my_db'" in content

The “Modern Engineering” Perspective

In high-stakes environments, fixtures are used for more than just files:

• ETL & Big Data: A fixture can initialize a SparkSession or create a temporary schema in Snowflake/BigQuery for data validation.
• API Testing: Use fixtures to generate an OAuth2 Token once and reuse it across multiple test cases.
• AI/ML: Use fixtures to load a Heavy Model into memory once (using session scope) so you don't reload it for every single test, saving minutes of execution time.

3. How do you run a test with Pytest?

You execute tests by running the pytest command in your terminal. Pytest automatically discovers your tests based on a set of conventions.

Test Discovery Rules:

• Files must be named test_.py or _test.py.
• Functions within those files must be named test_*.
• Classes must be named Test* (e.g., TestUser).

Command Examples

Assume you have a project with the following structure:

my_project/
├── my_module.py
└── tests/
 ├── test_database.py
 └── test_api.py

• To run all tests in the current directory and its subdirectories:

pytest

• To run a specific test file:

pytest tests/test_database.py

• To run a specific test function inside a file

pytest tests/test_api.py::test_create_user

4. What is an assertion in Pytest, and how do you use it?

An assertion is a statement that checks if a condition is true. It is the core of any test, as it’s how you verify that the code you’re testing is behaving as expected.

Pytest uses the standard Python assert keyword. If the condition following assert is False, Pytest catches the failure and provides a detailed error message, making it easy to debug.

# A simple function to test
def divide(a, b):
 return a / b

# A test case with assertions
def test_division_by_two():
 result = divide(10, 2)
 # This assertion checks if the result is equal to 5.0
 assert result == 5.0
def test_division_by_zero():
 # This assertion checks if calling divide(10, 0) raises a ZeroDivisionError
 import pytest
 with pytest.raises(ZeroDivisionError):
 divide(10, 0)

Pytest’s output for a failing assertion is highly informative. For example, if you ran assert divide(10, 2) == 6, Pytest would show E assert 5.0 == 6, clearly indicating that the actual value was 5.0 while the expected value was 6.

5. What is the difference between assert and assert not in Pytest?

While both use the assert keyword, they check for opposite conditions.

• assert checks if a condition is truthy (evaluates to True).
• assert not checks if a condition is falsy (evaluates to False).

This is a standard Python concept that applies directly to Pytest.

def test_data_and_api_logic():
    # 1. API Context: Asserting a successful response
    status_code = 200
    assert status_code == 200  # Passes because the condition is True

    # 2. ETL/Big Data Context: Asserting no null values in a dataset
    null_records = [] 
    assert not null_records    # Passes because an empty list is "Falsy"

    # 3. AI/ML Context: Asserting a model is NOT uninitialized
    model_weights = [0.12, 0.45, 0.88]
    assert model_weights       # Passes because a populated list is "Truthy"

    # 4. Negative Testing: Asserting an error message is NOT present
    error_message = ""
    assert not error_message   # Passes because an empty string is "Falsy"

6. What is the pytest.ini file, and what is its purpose?

The pytest.ini file is a configuration file that allows you to customize and control Pytest’s behavior for your project. You place this file in the root directory of your project.

Its main purpose is to standardize test execution for everyone on your team. This prevents developers from needing to remember specific command-line arguments.

# Tell Pytest where to look for tests
testpaths = tests src

# Register a custom marker
markers =
 slow: mark a test as slow to run
# Set a default command-line option
addopts = -v --strict-markers

With this file, anyone running pytest from the project’s root will automatically use these settings. For instance, running pytest -m “not slow” will skip all tests marked with @pytest.mark.slow.

7. How do you write a test case in Pytest?

You write a test case by creating a regular Python function that follows the Pytest naming conventions (starts with test_). Within this function, you include one or more assert statements to verify the behavior of your code.

import pytest

# 1. The Function to be tested (Logic)
def calculate_data_health(record_count, error_count):
    if record_count == 0:
        return 0
    return (1 - (error_count / record_count)) * 100

# 2. A Simple Functional Test Case
def test_calculate_data_health_success():
    """Verifies that data health is calculated correctly for valid inputs."""
    score = calculate_data_health(100, 5)
    assert score == 95.0

# 3. An ETL-style Test Case (Checking for empty/falsy results)
def test_etl_cleansing_empty_errors():
    """Verifies that an empty list of errors results in 100% health."""
    errors = [] # Simulating a clean data run
    score = calculate_data_health(100, len(errors))

    assert score == 100.0
    assert not errors  # Using 'assert not' to ensure the list is empty

# 4. An API-style Test Case (Using Mock-like logic)
def test_api_response_format():
    """Verifies that a simulated API response contains the required key."""
    response = {"status": "success", "data": {"id": 101}}

    assert response["status"] == "success"
    assert "data" in response

8. What is a test suite in Pytest?

In Pytest, a test suite is a collection of related tests. Unlike other frameworks that might require a specific class or object to define a suite, Pytest’s approach is simpler and more organic: a test suite is simply a logical grouping of tests.

This grouping is typically achieved by placing related test functions into a single test file or organizing multiple test files within a dedicated directory.

9. How do you skip a test in Pytest?

You can skip a test using Pytest’s markers, which are decorators that you add to a test function. The two main decorators for skipping tests are:

• @pytest.mark.skip: Unconditionally skips a test.
• @pytest.mark.skipif: Skips a test based on a specific condition.

import pytest
import sys

# 1. Unconditional Skip
# Use this when a feature is deprecated or a known bug is being fixed.
@pytest.mark.skip(reason="JIRA-101: Fix in progress for the Login API")
def test_api_login_deprecated():
    assert call_login_api() == 200

# 2. Conditional Skip (The 'Expert' Way)
# Perfect for ETL/AI testing where resources (like Spark or GPU) might be missing.
DATABASE_AVAILABLE = False # This would usually be a check in your config

@pytest.mark.skipif(not DATABASE_AVAILABLE, reason="Skipping ETL test: Snowflake connection not found")
def test_snowflake_data_load():
    assert run_etl_pipeline() == "Success"

# 3. Skipping based on Python Version or OS
@pytest.mark.skipif(sys.platform == "win32", reason="Linux-specific Big Data tool; does not run on Windows")
def test_linux_pyspark_optimization():
    assert optimize_spark_performance() is True

10. How do you parametrize a test in Pytest?

Parametrization is a powerful technique that allows you to run the same test function multiple times with different sets of input data and expected outputs. This drastically reduces code duplication and makes your tests more concise and maintainable.

You use the @pytest.mark.parametrize decorator to achieve this.

import pytest

# Example 1: ETL / Data Validation
# Testing different data types or edge cases in a pipeline
@pytest.mark.parametrize("raw_data, status", [
    ("valid_string", "PROCESSED"),
    ("", "EMPTY_ERROR"),
    (None, "NULL_ERROR"),
    ("12345", "PROCESSED"),
])
def test_etl_cleansing_rules(raw_data, status):
    # Imagine a function 'clean_data' that returns a status
    from my_etl_module import clean_data
    assert clean_data(raw_data) == status

# Example 2: API Testing
# Testing multiple HTTP status codes for a single endpoint
@pytest.mark.parametrize("user_role, expected_status", [
    ("admin", 200),
    ("editor", 200),
    ("viewer", 403), # Unauthorized access check
])
def test_api_access_control(user_role, expected_status):
    # Simulated API call
    response_code = call_api_as_role(user_role)
    assert response_code == expected_status