You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
This maps well to the AAA pattern, but what if I want to call multiple apis, to test a "story", a "flow"?
Example:
You don't explicitly say that there should be only one Act but I've found this quite upvoted post that says:
That post is about unit testing and I see how it makes perfect sense for unit testing. My questions are:
Thanks
The text was updated successfully, but these errors were encountered: