Skip to main content

A quick unittest-compatible framework for repeating a test function over many fixtures

Project description

Join the chat at https://gitter.im/epsy/repeated_test https://github.com/epsy/repeated_test/actions/workflows/ci.yml/badge.svg?branch=master https://coveralls.io/repos/github/epsy/repeated_test/badge.svg?branch=master

repeated_test lets you write tests that apply the same function to many sets of parameters.

For instance:

from repeated_test import Fixtures

class MyFixtures(Fixtures):
    def _test(self, expected, *terms):
        self.assertEqual(expected, sum(terms))

    a = 10, 5, 5
    b = 15, 7, 8
    c = 42, 1, 1

The result is unittest-compatible, and provides useful context in the traceback in case of errors:

$ python -m unittest my_tests
..F
======================================================================
FAIL: test_c (my_tests.MyFixtures)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "my_tests.py", line 9, in MyFixtures
    c = 42, 1, 1
  File "my_tests.py", line 5, in _test
    self.assertEqual(expected, sum(terms))
AssertionError: 42 != 2

----------------------------------------------------------------------
Ran 3 tests in 0.002s

FAILED (failures=1)

You can install it using:

$ pip install --user repeated_test

Help / Issues

You can get help in the gitter.im chatroom.

If you find any issues or have any requests, use GitHub Issues.

Reference

Introduction

Python’s unittest modules helps in performing various forms of automated testing. One writes a class deriving from unittest.TestCase and adds various test_xyz methods. Test runners run these tests, keeping count of successful and failed tests, and produces a trace with the causes of these failures.

Sometimes it makes sense to have one test be carried out for a large amount of different inputs. This module aims to provide an efficient way to do this.

It allows you to write fixtures (inputs) as plain members of a class, and bind a test function to them. This test function is called for each fixture as you will see below. The produced class is a unittest.TestCase subclass, so it is compatible with unittest and other unittest-compatible test runners.

Building a test case

In order to produce a unittest.TestCase, repeated_test requires you to:

  • Subclass repeated_test.Fixtures

  • Write a _test method that takes a few parameters, making use of any unittest.TestCase method it needs

  • Assign fixtures directly in the class body, which are then unpacked as arguments to the _test method (as in _test(*args))

You can use any unittest.TestCase methods in your test function, such as assertEqual() and so forth.

from repeated_test import Fixtures

class MyFixtures(Fixtures):
    def _test(self, arg1, arg2, arg3):
        self.assertEqual(..., ...)

    Ps = 'p1', 'p2', 'p3'
    # _test(*Ps) will be called, ie. _test('p1', p2', 'p3')

    Qs = 'q1', 'q2', 'q3'
    # _test(*Qs) will be called, ie. _test('q1', q2', 'q3')

Make sure that your fixture tuples provide the correct amount of arguments for your _test method, unless it has an *args parameter.

Running a test case

You can run a repeated_test test case like any other unittest.TestCase class:

python -m unittest
python -m unittest my_test_module
python -m unittest my_test_module.MyFixtures

# To refer to an individual test, prefix the name of the fixture with "test_"
python -m unittest my_test_module.MyFixtures.test_Ps

Learn more in the official unittest docs.

You can also use a unittest-compatible test runer, like pytest:

python -m pytest
python -m pytest my_test_module.py
python -m pytest my_test_module.py -k MyFixtures
python -m pytest my_test_module.py -k test_Ps
python -m pytest my_test_module.py::MyFixtures::test_Ps

Learn more in the official pytest docs

Passing in keyword arguments

You can pass in keyword arguments using repeated_test.options:

import sys

from repeated_test import Fixtures, options

class MyFixtures(Fixtures):
    def _test(self, arg1, arg2, *, min_version=None, max_version=None):
        ...

    not_using_versions = "abc", "abc"
    # -> _test("abc", "abc")

    using_max_version = "abc", "abc", options(max_version=(3, 9))
    # -> _test("abc", "abc", max_version=(3, 9))

    using_both_versions = "abc", "abc", options(min_version=(3, 8), max_version=(3, 9))
    # -> _test("abc", "abc", min_version=(3, 8), max_version=(3, 9))

    using_both_versions_2 = "abc", "abc", options(min_version=(3, 8)), options(max_version=(3, 9))
    # Same, but by specifying options separately

This can be useful if you have multiple options that are only used some of the time.

Passing in keyword arguments to multiple tests

If you are re-using the same keyword arguments across multiple tests, there are several ways to do so:

  • Using @repeated_test.with_options(...) lets you specify options for every fixture within a class.

  • Using with repeated_test.options(...) lets you specify options for every fixture within the with block.

  • You can continue using options() on individual fixtures, and override values provided by surrounding code.

  • You can use repeated_test.skip_option to stop supplying any argument. The argument won’t be supplied to the function, which is useful for using a default value, or for removing common options from a class whose test function doesn’t handle

from repeated_test import Fixtures, options, with_options

@with_options(kwarg1="value from decorator")
class MyFixtures(Fixtures):
    def _test(self, arg1, arg2, *, kwarg1, kwarg2="default"):
        ...

    using_provided_values = "arg1", "arg2"
    # -> _test("arg1", "arg2", kwarg1="value from decorator", kwarg2="default")

    overriding_provided_values = "arg1", "arg2", options(kwarg1="kwarg1", kwarg2="kwarg2")
    # -> _test("arg1", "arg2", kwarg1="kwarg1", kwarg2="kwarg2")

    with options(kwarg1="value from context manager"):
        using_value_from_context_manager = "arg1", "arg2"
        # -> _test("arg1", "arg2", kwarg1="value from context manager", kwarg2="default")

        overriding_value_from_context_manager = "arg1", "arg2", options(kwarg1="kwarg1")
        # -> _test("arg1", "arg2", kwarg1="kwarg1", kwarg2="default")

    with options(kwarg2="value from context manager"):
        removing_value = "arg1", "arg2"
        # -> _test("arg1", "arg2", kwarg1="value from decorator", kwarg2="value from context manager")
        removing_value = "arg1", "arg2", options(kwarg2=skip_option)
        # -> _test("arg1", "arg2", kwarg1="value from decorator", kwarg2="default")

Testing multiple values for a keyword parameter

You can also use @with_options_matrix to provide multiple values for a keyword parameter. repeated_test will run every combination except for parameters that are overridden.

from repeated_test import Fixtures, options, with_options_matrix


@with_options_matrix(
    spam=["spam1", "spam2"],
    ham=["ham1", "ham2"],
)
class MyFixtures(Fixtures):
    def _test(self, arg1, arg2, *, spam, ham):
        ...

    using_provided_values = "arg1", "arg2"
    # -> _test("arg1", "arg2", spam="spam1", ham="ham1")
    # -> _test("arg1", "arg2", spam="spam1", ham="ham2")
    # -> _test("arg1", "arg2", spam="spam2", ham="ham1")
    # -> _test("arg1", "arg2", spam="spam2", ham="ham2")

    with options(spam="spam"):
        overriding_one_value = "arg1", "arg2"
        # -> _test("arg1", "arg2", spam="spam", ham="ham1")
        # -> _test("arg1", "arg2", spam="spam", ham="ham2")

repeated_test will report each combination using unittest’s subtests feature. pytest does not have this feature built-in, but the pytest-subtests plugin adds support.

======================================================================
FAIL: test_overriding_one_value (example_options._test) (ham='ham1')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/myself/repeated_test/example_options.py", line 41, in MyFixtures
    overriding_one_value = "arg1", "arg2"
  File "/home/myself/repeated_test/example_options.py", line 32, in _test
    self.fail("example failure")
AssertionError: example failure

======================================================================
FAIL: test_overriding_one_value (example_options._test) (ham='ham2')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/myself/repeated_test/example_options.py", line 41, in MyFixtures
    overriding_one_value = "arg1", "arg2"
  File "/home/myself/repeated_test/example_options.py", line 32, in _test
    self.fail("example failure")
AssertionError: example failure

Evaluated test case input

You can use @evaluated to make a function that can be inserted in a test case tuple. When running the test, the function will be called, and the result will be spliced into the test case tuple:

from repeated_test import Fixtures, evaluated

class EvaluatedFixtures(Fixtures):
    def _test(self, a, b, c):
        pass

    @evaluated
    def fully_evaluated(self):
        return (1 + 1, 2, 3)
    # -> _test(2, 2, 3)

    @evaluated
    def _helper():
        return (1 + 2, 3)
    partly_evaluated = _helper(), 4
    # -> _test(3, 3, 4)

The wrapped function must always return a tuple.

The wrapped function will also receive options as keyword arguments:

from repeated_test import Fixtures, evaluated, with_options_matrix

@with_options_matrix(
    option=[
        "option 1",
        "option 2",
    ],
)
class EvaluatedFixturesWithOptions(Fixtures):
    def _test(self, a, *, option):
        pass

    @evaluated
    def _helper(arg, *, option):
        return (f"{arg}-{option}",)

    using_option_in_evaluated = _helper("arg")
    # -> _test("arg-option 1", option="option 1")
    # -> _test("arg-option 2", option="option 2")

Named alternatives

When using with_options_matrix, sometimes the repr generated by those options is difficult to read. This can be the case with functions, which can end up showing as something like <function myfunc at 0x7f9f5e506280>.

You can use NamedAlternative to give them a name:

from repeated_test import NamedAlternative

value1 = NamedAlternative("name for value1", "value1")

@NamedAlternative("name for func1")
def func1():
    pass

Naming and escaping

You may name your test tuples however you like, though they may not start with test_ or _. They are copied to the resulting unittest.TestCase class, and test methods are created for them. Their name is that of the tuple, prefixed with test_.

Members starting with test_ or _ are directly copied over to the resulting unittest.TestCase class, without being treated as fixtures. You can use this to insert regular tests amongst your fixtures, or constants that you do not wish to be treated as tests:

from repeated_test import Fixtures

class MyFixtures(Fixtures):
    def _test(self, arg1, arg2, arg3):
        self.assertEqual(..., ...)

    def test_other(self):
        self.assertEqual(3, 1+2)

    _spam = 'spam, bacon and eggs'
    # _spam won't be treated as a fixture, so _test(*_spam) won't be called

    ham = _spam, _spam, _spam

You may even call the test function using self._test(...) if necessary.

Separating tests and fixtures

You can apply a fixtures class to a different test function using its with_test method:

class MyFixtures(Fixtures):
    _test = None
    ...

@MyFixtures.with_test
def other_test(self, arg1, arg2, arg3):
    self.assertEqual(..., ...)

While the function appears out of any class, it will be used as a method of the resulting unittest.TestCase class, so keep in mind that it takes a self parameter.

You can reuse a fixture class however many times you like.

If you specify a test function this way, you can set _test = None in your fixtures definition. However, it will not be discovered by unittest, so regular test methods won’t be run. Omitting _test completely raises an error in order to prevent accidentally disabling your tests.

Working with functions as fixtures

It can be fairly impractical to use functions in your fixture tuples in this scheme. If your fixture tuple is meant to have one function in it, you can use the tup decorator:

from repeated_test import Fixtures, tup

class my_tests(Fixtures):
    def _test(self, func, arg1, arg2):
        self.assertEqual(..., ...)

    @tup('arg1', 'arg2')
    def ham():
        pass
    # equivalent to
    def _ham():
        pass
    ham = _ham, 'arg1', 'arg2'

Replacing unittest.TestCase with another class

You can replace unittest.TestCase with another class using WithTestClass(cls).

For instance, if you wish to use unittest2:

import unittest2
from repeated_test import WithTestClass

class my_tests(WithTestClass(unittest2.TestCase)):
    ...

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

repeated_test-2.3.3.tar.gz (19.1 kB view details)

Uploaded Source

Built Distribution

repeated_test-2.3.3-py2.py3-none-any.whl (16.2 kB view details)

Uploaded Python 2 Python 3

File details

Details for the file repeated_test-2.3.3.tar.gz.

File metadata

  • Download URL: repeated_test-2.3.3.tar.gz
  • Upload date:
  • Size: 19.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.9.17

File hashes

Hashes for repeated_test-2.3.3.tar.gz
Algorithm Hash digest
SHA256 dd83d4f122fdaee779b34a67c301f94c9935317b0385d9039d9a7f3a3eac817b
MD5 510f38c9623e6b5dee2591ef4ecf915a
BLAKE2b-256 99780911cdbd699c72701ba6755e7696d075bad52047ad6cd1e8976b08ded099

See more details on using hashes here.

File details

Details for the file repeated_test-2.3.3-py2.py3-none-any.whl.

File metadata

File hashes

Hashes for repeated_test-2.3.3-py2.py3-none-any.whl
Algorithm Hash digest
SHA256 0036c4103438304fdec107ec4a3eac83adc854c88f95b7fe3245e2296cbfdd13
MD5 fbb02d8d723dfc66428b1104a0c581a5
BLAKE2b-256 6fc325590e565adea5263802aa01ed954c2f71234a049a8b495e66111134d0b2

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page