Python Unit Testing (unittest, pytest) Exercises

The simplest way to run tests using pytest is to execute the pytest command from the terminal inside your project directory. By default, it will automatically discover files following the pattern test_*.py or *_test.py, and execute all the test functions inside them.

Options like run_tests.py or python -m runall are not standard pytest commands. While unittest.run() can be used in Python’s built-in unittest framework, it is not relevant when using pytest.

When writing unit tests with Python’s built-in unittest framework, we typically define our test classes by inheriting from unittest.TestCase. This gives access to many useful assertion methods such as assertEqual, assertTrue, assertRaises, and more.

For example:

import unittest

class MyTests(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(2 + 2, 4)

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

This ensures our test class integrates smoothly with the unittest discovery and execution process. Other options like BaseTest, UnitTest, or Case are not valid in the unittest module.

In the unittest framework, the correct way to verify that two values are equal is by using assertEqual(a, b). This method raises an error if a != b, making it one of the most frequently used assertions in unit testing.

For example:

import unittest

class MathTests(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(2 + 3, 5)

Other options like assertSame(), assertEqualsTo(), and assertCheckEqual() do not exist in Python’s unittest module.

When using pytest, the test discovery mechanism automatically identifies functions whose names start with test_. This naming convention ensures that pytest recognizes them as valid test cases without requiring additional configuration.

For example:

def test_division():
    assert 10 / 2 == 5

Options like starting with case_, ending with _unit, or using uppercase names do not match pytest’s discovery rules. Following the correct convention is essential to make tests run automatically.

To run pytest tests from the command line, the most common and recommended way is using:

python -m pytest

This command ensures Python invokes pytest as a module, which works across environments and avoids path-related issues. You can also just run pytest directly if pytest is installed globally, but using python -m pytest is more reliable.

Options like pytest.run, python pytest.py, or pytest execute are incorrect and not recognized by pytest.

The method setUpClass() is executed once before any test methods in a TestCase class run. It is defined as a @classmethod and is typically used to set up expensive resources that are shared across tests.

Example:

import unittest

class SampleTests(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        print("Run once before all tests")

    def test_one(self):
        self.assertTrue(True)

On the other hand:

• setUp() runs before each individual test, not once.
• tearDown() runs after each test, used for cleanup.
• initTests() does not exist in unittest.

In pytest, you can mark a test to be skipped using the decorator:

import pytest

@pytest.mark.skip(reason="Feature not implemented yet")
def test_future_feature():
    assert 1 == 2

This ensures the test will be skipped during execution with a clear reason displayed in the test report.

• Option 1 (@pytest.skip("reason")) is invalid because skip is not a decorator.
• Option 2 (skip_test("reason")) does not exist in pytest.
• Option 4 (pytest.skip_test) is not a recognized function.

The correct and widely used approach is @pytest.mark.skip with a reason parameter.

In pytest, the @pytest.mark.skipif(condition, reason="...") marker is used to skip tests when a given condition evaluates to True. This is extremely useful when tests depend on external libraries, operating systems, or Python versions.

Example:

import sys
import pytest

@pytest.mark.skipif(sys.platform == "win32", reason="Does not run on Windows")
def test_linux_feature():
    assert True

Here:

• If running on Windows, the test will be skipped.
• Options 1, 2, and 4 are invalid markers or functions that don’t exist in pytest.

So the correct answer is option 3.

In Python’s built-in unittest framework, the assertRaises method is the standard way to verify that a certain piece of code raises an exception.

Example:

import unittest

def divide(a, b):
    return a / b

class TestMath(unittest.TestCase):
    def test_divide_by_zero(self):
        self.assertRaises(ZeroDivisionError, divide, 10, 0)

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

Here:

• self.assertRaises(ZeroDivisionError, divide, 10, 0) confirms that dividing by zero raises the expected error.
• Options 2, 3, and 4 are invalid methods that do not exist in unittest.

Thus, option 1 is correct.

Pytest provides the --lf (last-failed) option to rerun only the tests that failed in the last test execution. This feature is especially useful in large projects to save time by not rerunning all tests unnecessarily.

For example:

pytest --lf

This will execute only the failed tests from the previous test run.

• Option 1 (--only-failed) does not exist in pytest.
• Option 2 (--failed-first) is a valid option, but it runs failed tests first, then executes the remaining ones.
• Option 4 (--rerun-failures) requires a plugin (pytest-rerunfailures) and is not built-in.

Therefore, the correct answer is option 3: pytest --lf.

Python’s unittest framework allows you to use assertRaises as a context manager, which is cleaner and more readable when testing for exceptions in a block of code.

Example:

import unittest

def divide(a, b):
    return a / b

class TestMath(unittest.TestCase):
    def test_divide_by_zero(self):
        with self.assertRaises(ZeroDivisionError):
            divide(10, 0)

• Option 1 (assertException) does not exist.
• Option 3 (self.raises) is invalid.
• Option 4 (assertError) is also invalid.

Using with self.assertRaises(ExceptionType): is the standard approach in unittest for testing exceptions, making the code more readable than passing the function as arguments.

Pytest provides the @pytest.mark.parametrize decorator to run a single test function with multiple input values, reducing code duplication. This is especially useful for testing multiple scenarios with the same logic.

Example:

import pytest

@pytest.mark.parametrize("x", [1, 2, 3])
def test_square(x):
    assert x * x >= 0

• Here, test_square will run three times, once for each value of x.
• Options 1, 3, and 4 are invalid decorators and will not work in pytest.

Parametrization allows you to keep tests concise, readable, and maintainable while covering multiple cases efficiently.

Pytest fixtures can have different scopes to control how often the setup/teardown code runs.

• scope="function" runs before each test function.
• scope="class" runs once per test class.
• scope="session" runs once per test session.
• scope="module" runs once per Python module, making it ideal when multiple tests in a module share the same setup.

Example using a SolutionBazz-like API:

import pytest

@pytest.fixture(scope="module")
def setup_module_data():
    print("Setting up module data")
    return {"url": "https://api.solutionbazz.com/tests"}

Using module scope can reduce redundant setup and speed up test execution when multiple tests depend on shared resources.

The tearDown() method in unittest runs after each test method in a TestCase. It is typically used to release resources, close files, or reset states modified during the test.

Example:

import unittest

class FileTests(unittest.TestCase):
    def setUp(self):
        self.file = open("sample.txt", "w")

    def test_write(self):
        self.file.write("Hello, SolutionBazz!")
        self.assertFalse(self.file.closed)

    def tearDown(self):
        self.file.close()

• tearDownClass() runs once after all tests in a class.
• cleanup() and postTest() are not valid unittest methods.

Using tearDown() ensures that each test is isolated and doesn’t interfere with others, which is crucial for reliable unit testing.

Pytest allows you to skip tests using the @pytest.mark.skip decorator. This is useful when a feature is not implemented yet or temporarily broken, allowing you to keep the test in your codebase without executing it.

Example:

import pytest

@pytest.mark.skip(reason="Feature not implemented")
def test_future_feature():
    assert 1 == 2

• The test will be reported as skipped, and the reason will be shown.
• Options like @pytest.disable and @pytest.ignore do not exist in pytest.
• @pytest.skipif(False) is used for conditional skipping, not unconditional.

Unit tests should be fast, deterministic, and isolated. Directly calling an external API like SolutionBazz can make tests slow and flaky. The best practice is to mock API responses using tools like unittest.mock or pytest-mock. This allows you to simulate API responses without actually making network requests.

Example using unittest.mock:

from unittest.mock import patch
import requests

def fetch_data(url):
    response = requests.get(url)
    return response.json()

@patch("requests.get")
def test_fetch_data(mock_get):
    mock_get.return_value.json.return_value = {"status": "ok"}
    result = fetch_data("https://api.solutionbazz.com/data")
    assert result["status"] == "ok"

• Mocking ensures tests are fast, reliable, and independent of network conditions.
• Options 1 and 2 are inefficient and unreliable.
• Option 4 hides problems instead of testing properly.

When writing cross-platform tests, some functionality may only be valid on specific operating systems. Pytest allows you to conditionally skip tests using @pytest.mark.skipif(). The test will be executed only if the condition is False.

Example:

import sys
import pytest

@pytest.mark.skipif(sys.platform != "linux", reason="Linux only")
def test_linux_feature():
    assert True

• This ensures the test is skipped automatically on non-Linux platforms.
• Options 1 and 2 are invalid approaches.
• Option 3 skips the test unconditionally, which is not desired.

Using skipif allows the test suite to remain portable and only execute relevant tests depending on the environment.

When testing function calls with unittest.mock, assert_called_once() is used to verify that a mocked function was called exactly once, regardless of its arguments. This is crucial when testing interactions in code, ensuring that a function is not inadvertently called multiple times.

Example:

from unittest.mock import Mock

mock_func = Mock()
mock_func()
mock_func.assert_called_once()

• Option 1 (assert_called) only checks if the function was called at least once.
• Option 3 (assert_called_once_with(args)) checks both call count and arguments, which is stricter.
• Option 4 (assert_called_n_times) does not exist in unittest.mock.

Using assert_called_once() provides a clear and concise way to validate that the function is called exactly once in your test scenario.

Pytest-asyncio provides support for testing async functions. To run an async test, you must use the @pytest.mark.asyncio decorator. This ensures the test is executed in an event loop, allowing you to await asynchronous calls.

Example:

import pytest
import asyncio

async def async_add(a, b):
    await asyncio.sleep(0.1)
    return a + b

@pytest.mark.asyncio
async def test_async_add():
    result = await async_add(2, 3)
    assert result == 5

• Without the decorator, pytest will treat the async function as a normal function, causing errors.
• Options 2, 3, and 4 are invalid; they do not exist in pytest-asyncio.

Using @pytest.mark.asyncio ensures reliable testing of asynchronous functions in Python projects.

Pytest provides the pytest.mark.timeout decorator (via the pytest-timeout plugin) to enforce a maximum allowed execution time for a test. If the test exceeds the time limit, it will fail automatically. This is ideal for performance-sensitive code, such as interacting with APIs in SolutionBazz.

Example:

import pytest
import time

@pytest.mark.timeout(2)
def test_slow_function():
    time.sleep(1.5)  # Should pass

• Option 1 (manual sleep) is unreliable and doesn’t enforce limits.
• Option 2 (unittest.timeit()) does not exist; timeit is a separate module.
• Option 3 (pytest.benchmark()) is used for benchmarking but doesn’t fail the test if it exceeds a max duration.

Using pytest.mark.timeout ensures your tests fail gracefully when performance thresholds are exceeded, making it perfect for robust unit testing in large projects.