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

[zatloeri]

I am no expert, but let me offer my humble opinion:

does AAA as described in this repo implies only one Act per test?

It depends on your point of view (what you mean by "one Act").
The important thing for me is to keep the tests predictable, readable and isolated.
So if I am testing fetchData and if its being cached for example:

1. arrange
   1. setupDatabase();
2. act
   1. data1 = fetchData();
   2. updateDataInDb();
   3. data2 = fetchData();
3. assert
   4. assertEqueal(data1, data2);
   5. assertSomethingElse();

You could say I am acting multiple times, or you could even see the updateDataInDb(); as another arrange.
From my point of view its important, that I am asserting after the acting is all done and that the prerequisites that I need to be even able to start the "acting" are separate from the act that I am trying to assert on.

Basically it could be reduced into "When I do this act given this arrangement I assert, that it produces a certain result".

does AAA as described in this repo applies only to unit testing?

I would say generally no. Having your tests abide by AAA is beneficial for Functional, Integration, Unit, Smoke, etc. tests as well.
Where I personally draw the line for AAA is End to End tests. There it does not make sense for me from multiple standpoints (performance, added value, etc.).

is there an official name for my type of tests other than "API tests"?

These days, the teminology around tests seems pretty inconsistent as different domains need different type of testing, so people are inventing "new types of tests" each day. I have heard what you describe being called "API Tests", "System Tests" or "Functional Tests".

If your domain is the API itself and your "users" and by extensions use cases are usages of the API, then I would say these are Functional Tests, but I am no testing expert.

does it make sense to have what I call "story/flow" tests? or should I just stick to one api call per test?

You can write the tests to suite your needs.
But keep in mind, that any developer, that needs to work on the given project will have to "learn" your way of testing, if it is not aligned with best practices or some standard.
Also be aware of the pitfalls and consider if that is worth it for your team.

For me, this approach is not good for tests, that will be maintained by multiple people, that also might not have the whole domain knowledge. It might be:

• hard to see what is the intention in the test (what is actually being tested).
• harder to debug as the test will probably be more complex than testing a single act.
  • it could also be missleading as some assertion might not be perfect and it might fail on subsequent assertion even though the problem occured in a previous act
• harder to change if requirements change
• cause that minor change in one part of the system will cause multiple tests to fail across the whole system
• ...

These kinds of tests are effective in "code coverage" and can work if the team is small or aligned with this approach. But I would generally leave these "scenario type" of tests to End to End testing. Or at least not have them as the primary type of tests in your application.