Data-driven testing

parameters accepts a plain function, not just a hardcoded list - so the actual data can come from anywhere: a CSV export, a JSON fixture, a database query. Test Junkie doesn't care, it just calls the function and runs your test once per item it returns.

test_account_provisioning.pypython

from test_junkie.decorators import Suite, beforeClass, afterClass, test


def load_test_accounts():
    # in a real project this might read a CSV/JSON fixture file -
    # what matters is that this is just a plain function returning a list
    return [
        {"username": "alice", "plan": "free"},
        {"username": "bob", "plan": "pro"},
        {"username": "carol", "plan": "pro"},
    ]


@Suite()
class AccountProvisioningSuite:

    @beforeClass()
    def open_session(self):
        # runs once, before any parameterized test below
        self.session = requests.Session()

    @afterClass()
    def close_session(self):
        # runs once, after every parameterized run has finished
        self.session.close()

    @test(parameters=load_test_accounts)
    def test_account_gets_correct_plan_limits(self, parameter):
        # this test body runs 3 times, once per item load_test_accounts() returned
        account = provision_account(self.session, parameter["username"], parameter["plan"])
        assert account["plan"] == parameter["plan"]

One session, many parameters

beforeClass/afterClass run once for the whole suite, not once per parameter - so the session above is shared across all three account checks instead of being rebuilt on every run.

Parameterizing the suite itself

The same parameters pattern works on @Suite() too - useful when beforeClass itself needs the data (e.g. logging in as a different account per suite run).