Reputation: 901
I have a REST API and I want to write an integration test for a POST endpoint, which creates a Foo item in the database. In the test scenario I am making a request to this POST endpoint. In the assertion part of the test, should I check the database to see if the endpoint in fact inserted the item posted, or should I call a GET endpoint for the Foo entities of the REST API and see if that returns the correct result?
I saw the latter in many examples, but it seems wrong to me, like I am testing two things with two API calls in a single test case. I can imagine a scenario where both my POST and GET endpoints are faulty, and the test still goes green that way.
Upvotes: 1
Views: 216
Reputation: 521
In my opinion, it depends on your test strategy and goals. Each approach has pros and cons. Let's mention some of them.
Pros: Reliable, independent verification.
Cons: It breaks API-Centric testing because an integration test usually focuses on the API's behaviors.
Pros: API-centric (it allows you to test a complete workflow), More realistic (it reflects the behavior of the users using the APIs)
Cons: It is dependent and relies on another endpoint (as you already mentioned)
I prefer using the GET method instead of querying the database because an integration test is not about focusing on the internal implementation details like the database, but combining both approaches is possible (especially when you are not sure that the GET endpoint works correctly).
Steps to take for the combination approach:
1- make post request
2- assert response.status_code
of the post request
3- make get request
4- assert response.status_code
of the get request
5- assert whether the foo
item is in the response body
6- query the database
7- assert foo
item
Upvotes: 1