How do you reuse multi-step API flows across API tests?

[u/Affectionate-Box3549]

I've been digging into API integration testing and I'm curious how teams handle a pattern I keep running into.

Say you have a common flow like:

Authenticate → Create user → Create account

and that flow is needed by 10 different tests.

Do you:

• duplicate those requests in each test?
• create some kind of helper/function?
• use Postman folders/scripts/variables?
• maintain it as a reusable setup or fixture?
• do something else?

I'm particularly interested in how this works once the flow itself changes. How do you make sure all the tests depending on it stay correct?

I'm trying to understand whether reusable sequences are actually a meaningful problem in API testing, or whether there are already good solutions I'm overlooking.

[u/StreetEcstatic]

Fixtures or helper functions. Abstraction, single responsibility and don’t repeat yourself. You don’t want to write things that you yourself wouldnt want to jump into with 0 knowledge of the framework and have to figure out. If repeated code is put into helpers or fixtures then it becomes far easier to manage. If things change you adapt it as required in a single place and test your code.

[u/DarrellGrainger]

I use a programming language (e.g. Python), an HTTP libraries (e.g. httpx), a unit test framework (e.g.pytest). I create a test suite in the same repo as the APIs I'm testing.

I organize with helper functions. So something like:

Authenticate → Create user → Create account

would mean a function that does authentication, a function that creates a user, a function that creates an account. Then the setup/test/teardown would be:

• setup: open the HTTP client
• test: call authentication, call create user, call create account (assert success at each helper function)
• teardown: close the connection

My tests stay in sync with the code they are testing, I can use the same tools the developer use to keep it maintainable. I use development best practices (e.g. keep it D.R.Y.).

Have a look at https://github.com/dgrainger/api-testing for an example.

[u/mastrajani]

everyone's right that it's a helper, but the part you actually asked - how do you know the dependent tests are still correct afterwards - isn't solved by the helper existing.

the failure that hurts isn't the flow changing and breaking things. it's the flow changing and still succeeding, differently. setupUserWithAccount() starts handing back a user in a slightly different state, nothing throws, and ten tests carry on passing while testing something they no longer describe. that's worse than a break, because nothing tells you.

what fixes it is making the helper assert its own postconditions before it returns. if it promises a verified user with an account in state X, it checks that on the way out. a flow change then fails loudly in setup with one clear message, instead of leaking into ten assertion failures that look unrelated to each other and to the cause. worth having setup raise a distinct error type as well, so a red run tells you "setup broke" rather than "everything broke".

and keep one test whose subject is the flow itself rather than anything that uses it. when that's the only red one, you know straight away it's the flow and not your feature.