Does AAA applies to API/Integration testing?

[michele-amati]

ATM, in my api backend, I have about 10% unit tests and 90% of what I would call "API tests". I'd like to include some of the best practices explained in this great repo, but I'm not sure how.

The problem starts by finding a correspondence between what I call "API testing" and the concepts in this repo. This article is quite fitting. In your repo it might correspond to black-box testing and/or to integration testing but I'm not sure.

Example:

// Arrange
// setup server & database

// Act
// call http api

// Assert
// check status code/response

This maps well to the AAA pattern, but what if I want to call multiple apis, to test a "story", a "flow"?

Example:

// Arrange
// setup server & database

// Act
// call http api to create a resource

// Assert
// check status code/response

// Act again?
// call http api to update the previously created resource

// Assert again?
// check status code/response

// it can go on with a get, delete, etc...

You don't explicitly say that there should be only one Act but I've found this quite upvoted post that says:

Tests should fail for one reason only, but that doesn't always mean that there should be only one Assert statement. IMHO it is more important to hold to the "Arrange, Act, Assert" pattern.
The key is that you have only one action, and then you inspect the results of that action using asserts. But it is "Arrange, Act, Assert, End of test". If you are tempted to continue testing by performing another action and more asserts afterwards, make that a separate test instead.

That post is about unit testing and I see how it makes perfect sense for unit testing. My questions are:

• does AAA as described in this repo implies only one Act per test?
• does AAA as described in this repo applies only to unit testing?
• is there an official name for my type of tests other than "API tests"?
• does it make sense to have what I call "story/flow" tests? or should I just stick to one api call per test?

Thanks