Deduplicate Tests With Pytest: A Femtologging Example

Aug 13, 2025 by Henrik Larsen 54 views

Deduplicating Overflow Policy Builder Tests in femtologging with pytest Parametrization

Hey guys! Today, we're diving deep into a cool refactoring idea within the femtologging library. Specifically, we're going to talk about how to deduplicate overflow policy builder tests using pytest parametrization. This is gonna make our tests cleaner, more maintainable, and easier to understand. Let's get started!

The Problem: Code Duplication in Overflow Policy Tests

So, what's the big deal? Well, in the tests/test_file_handler.py file, there are three test methods that are, let's say, very similar. I am talking about:

test_overflow_policy_builder_block
test_overflow_policy_builder_timeout
test_overflow_policy_builder_drop

If you peek inside these tests, you'll notice they follow almost the same pattern. The only things that change are the overflow policy type (BLOCK, TIMEOUT, or DROP), the capacity, timeout values, and, of course, the expected outcome. This duplication isn't just an eyesore; it makes the tests harder to maintain and increases the chances of introducing bugs when making changes. We want to write robust tests, and that means making them DRY (Don't Repeat Yourself).

Think of it like this: imagine you have three slightly different recipes for the same dish. If you need to tweak something, you'd have to change it in three places! That's a recipe for disaster, literally. The same applies to our tests. We need to consolidate them into a single, efficient recipe.

Let’s break down why this duplication is a problem in more detail. When tests have a lot of code in common, it becomes difficult to quickly grasp what each test is specifically verifying. This makes it harder to identify the root cause of a failure and increases the time it takes to fix issues. Imagine scrolling through hundreds of lines of almost identical code just to find the one line that's different! That's not a fun way to spend your day. Moreover, if a bug is introduced in the common code, it might affect all three tests, making debugging even more complex. The duplicated tests also increase the overall size of the test suite, which can slow down the test execution time. When you're running tests frequently as part of a continuous integration pipeline, every second counts. By reducing duplication, we can make our tests run faster and provide quicker feedback.

The Suggested Solution: pytest Parametrization to the Rescue

Now for the good stuff! The solution is elegant and leverages a powerful feature of pytest: parametrization. Pytest parametrization allows us to run a single test function multiple times with different sets of inputs. It's like having a test function that can adapt to different scenarios without us having to write separate functions for each. How cool is that?

The idea is to replace those three duplicate tests with a single, parametrised test. Here's how the code looks:

@pytest.mark.parametrize(
    "policy, capacity, timeout_ms, messages, expected",
    [
        (OverflowPolicy.BLOCK.value, 2, None, ["first", "second", "third"], ["first", "second", "third"]),
        (OverflowPolicy.TIMEOUT.value, 1, 500, ["first"], ["first"]),
        (OverflowPolicy.DROP.value, 2, None, ["first", "second", "third"], ["first", "second"]),
    ],
)
def test_overflow_policy_builder_parametrised(tmp_path, policy, capacity, timeout_ms, messages, expected):
    path = tmp_path / f"policy_{policy}.log"
    cfg = PyHandlerConfig(capacity, 1, policy, timeout_ms=timeout_ms)
    with closing(FemtoFileHandler.with_capacity_flush_policy(str(path), cfg)) as handler:
        for m in messages:
            handler.handle("core", "INFO", m)
    assert path.read_text().splitlines() == [f"core [INFO] {m}" for m in expected]

Let's break this down step-by-step:

@pytest.mark.parametrize: This is the magic decorator that tells pytest to run this test multiple times with different parameters.
"policy, capacity, timeout_ms, messages, expected": These are the names of the parameters we're going to use in our test.
[...]: This is a list of tuples, where each tuple represents a different set of parameters. For example:
- (OverflowPolicy.BLOCK.value, 2, None, ["first", "second", "third"], ["first", "second", "third"]) tests the BLOCK policy.
- (OverflowPolicy.TIMEOUT.value, 1, 500, ["first"], ["first"]) tests the TIMEOUT policy.
- (OverflowPolicy.DROP.value, 2, None, ["first", "second", "third"], ["first", "second"]) tests the DROP policy.
def test_overflow_policy_builder_parametrised(...): This is our test function. It takes the parameters defined in the @pytest.mark.parametrize decorator as arguments.
Inside the test function: We use the parameters to configure the FemtoFileHandler and then assert that the output matches the expected result. We create a file path specific to the policy being tested, configure the handler with the provided capacity, policy, and timeout, write messages using the handler, and assert that the actual content of the file matches the expected content. This ensures that each policy type behaves as expected under different conditions.

With this single test function, we've effectively replaced three separate tests! This not only reduces code duplication but also makes our test suite more expressive and easier to understand. Each set of parameters represents a specific scenario, making it clear what we're testing.

Now, let's delve into the benefits of this approach in more detail. First and foremost, code duplication is significantly reduced. Instead of having three almost identical test functions, we have a single function that covers all scenarios. This makes the test suite much easier to maintain. If a bug is found in the common test logic, we only need to fix it in one place. The use of parametrization also makes the tests more explicit. Each set of parameters clearly defines a specific test case, making it easy to see what is being tested and what the expected outcome is. This can help in debugging and understanding test failures. Furthermore, parametrized tests are more flexible. If we need to add a new test case, we simply add a new set of parameters to the list. We don't need to write a new test function, which saves time and reduces the risk of introducing errors.

Benefits: Why This Rocks

So, why is this such a great idea? Let's break down the benefits:

Reduces Code Duplication: We've already hammered this point home, but it's worth repeating. Less code means less to maintain and fewer opportunities for bugs.
Improves Test Maintainability: When tests are concise and easy to understand, it's much easier to make changes and fix issues. This is crucial for long-term project health.
Makes Test Coverage More Explicit: Parametrization makes it crystal clear which scenarios are being tested. You can see at a glance the different policy types, capacities, and timeout values being exercised.
Follows pytest Best Practices: Pytest parametrization is a recommended way to write efficient and expressive tests. By using it, we're aligning with the best practices of the testing framework.

In addition to these core benefits, parametrized tests can also lead to improved readability. When a test fails, the pytest output will clearly indicate which set of parameters caused the failure. This can save a lot of time in debugging. Instead of having to manually inspect the test code and the data being used, the information is readily available in the test report. This makes it easier to pinpoint the exact cause of the failure and fix it quickly. Also, the ability to run the same test logic with different inputs can help uncover edge cases and hidden bugs that might not be caught by traditional testing methods. By systematically varying the inputs, we can increase the confidence in the robustness of our code.

Context: The Bigger Picture

This suggestion came about during a code review for this PR. The discussion around deduplication and parametrization can be found in this comment. Big shoutout to @leynos for requesting this refactoring!

In the context of a larger project, this kind of refactoring is essential for maintaining code quality and ensuring long-term maintainability. As projects grow, the test suite can become large and complex. If tests are not well-organized and DRY, they can become a burden rather than an asset. By adopting techniques like parametrization, we can keep our tests lean, mean, and easy to work with. This allows us to focus on adding new features and fixing bugs, rather than spending time wrestling with the test suite.

This is also a great example of how code reviews can lead to improvements in code quality. By having multiple pairs of eyes on the code, we can catch issues like code duplication and identify opportunities for refactoring. This can result in significant improvements in the overall quality of the codebase. So, next time you're reviewing code, be sure to look for opportunities to deduplicate code and use parametrization where appropriate.

Conclusion: Parametrization for the Win!

So, there you have it! We've seen how pytest parametrization can be used to deduplicate overflow policy builder tests in femtologging. This technique not only makes our tests cleaner and more maintainable but also improves test coverage and aligns with pytest best practices. Remember, writing good tests is just as important as writing good code. By using parametrization and other techniques, we can ensure that our tests are robust, efficient, and easy to understand. Keep coding, keep testing, and keep refactoring!

By replacing duplicate tests with a single parametrized test, we’ve made the femtologging test suite more robust, maintainable, and easier to understand. This not only saves time in the long run but also reduces the risk of introducing bugs. Remember, well-crafted tests are a cornerstone of software quality, and techniques like parametrization are essential tools in any developer's arsenal. So, go forth and deduplicate your tests! Your future self (and your teammates) will thank you for it.