Fast feedback loops

This isn't load testing

Test Junkie doesn't generate load or measure your application's performance - it's a test runner. What's below is about your own suite's execution speed: running a smaller, targeted slice of a large suite, in parallel, so you get a pass/fail signal in seconds instead of minutes.

Two independent levers get you there: filtering which tests run at all, and raising how many of them run at once.

1. Categorize as you write tests

feature is a suite-level label; component, tags, and owner are test-level - all of it is plain metadata, it doesn't change how a test runs on its own.

test_checkout.pypython

from test_junkie.decorators import Suite, test

@Suite(feature="Checkout")
class CheckoutSuite:

    @test(component="Payments", tags=["smoke", "critical-path"], owner="Alex", priority=1)
    def test_apply_discount_code(self):
        ...

    @test(component="Shipping", tags=["regression"], owner="Priya", priority=3)
    def test_calculate_shipping_cost(self):
        ...

2. Filter a run down to what matters right now

Called programmatically, the same metadata becomes a filter on Runner().run() - the same options are also available as CLI flags or a .tj.cfg file, see the CLI reference.

run_smoke.pypython

from test_junkie.runner import Runner

runner = Runner([CheckoutSuite])
runner.run(
    run_on_match_any=["smoke"],  # only tests tagged "smoke"
    test_multithreading_limit=8,
    suite_multithreading_limit=4,
)

Filter first, then parallelize

Raising thread limits on an unfiltered suite still runs everything, just faster - it doesn't replace picking the right subset. The two levers are independent and compose: filter down to the tests you actually need for this feedback loop, then raise the thread limits on what's left.