API Testing - Best Strategy to adopt

Question

I have few questions for you. Let me give some details before I throw the questions.

Recently I have been involved in Rest api test automation. We have a single rest api to fetch resources,( this api is basically used in our web app UI for different business workflows to get data) though its the same resource api, the actual endpoint varies accordingly for different situations .i.e the query parameters passed in the api url gets differed based on the business workflow.

For example something like

`./getListOfUsers?criteria=agedLessThanTen ../getListOfUsers?criteria=agedBetweenTenAndTwenty ../getListOfUsers?criteria=agedBetweenTwentyAndThirty etc

As there is only one api and as the business workflow do not demand it, we don't have chaining requests between apis So the test is just hitting on individual endpoints and validating the response content. The response are validated based on a supplied test data. So the test data file has list of users expecting when hit on each particular endpoint. i.e the test file is like a static content which will be used to check the response content everytime we hit on it... if the actual response retreived from server deviating with our supplied testdata,it will be a fialure. (also tests are there for no content respose,with out auth etc)

This test is ok to confirm the endpoints are working and response content is good or not .

My actual questions are on the test strategy or business covergae here,

1. Is such single hit on the api end point is sufficient here or not..

2. or same endpoint should be hit again for other scenarios or not, especially when the above given example of endpoints actually complimenting each other and a regression issues that might happen, can possible captured in anyof it ?

3. If api endpoints are complimenting each other, adding more tests , will it be just duplicate of tests/ more maintainance / and other problems later on and should we avoid it ? if its not giving values ?
4. Whats the general trend on API automation regarding the covergae? . I beleive it should be utilzed to test the business integration flows, and scenarios if it demands but for situations like this , is it really required
5. also should we keep this point in mind here ?, that automation is not to replace manual testing, but only to compliment it . and attempt to automate every possible scenario is not going to give value and only will give maintaince trouble later ?

Thanks

Answer 1

Is such single hit on the api end point is sufficient here or not..

Probably not, for each one you would want to verify various edge cases (e.g. lowest and highest vales, longest string), negative tests (e.g. negative numbers where only positive allowed) and other tests according to the business and implementation logic.

Whats the general trend on API automation regarding the covergae? ... automation is not to replace manual testing, but only to compliment it . and attempt to automate every possible scenario is not going to give value and only will give maintaince trouble later ?

If you build your test in a modular way then maintenance becomes less of an issue, you need to implement each API anyway and the logic and test data above that should be the less complicated part of the test system.

Indeed you usually want to have a test pyramid of many unit tests, some integration tests and fewer end to end tests, but in this case since there is no UI involved, the end user is just another software module, and execution time for REST APIs is relatively short and stability is relatively good then it is probably acceptable to have a wider end to end test layer.

I used a lot of conditionals above since it's only you that can evaluate the situation in light of the real system.

If possible consider generating test data on the fly instead of using hard coded values from a file, this will require a parallel logic implemented in your tests but will make maintenance and coverage an easier job.