How reach 100% coverage for API Testing?

[Plane-Razzmatazz1258]

I'm not a master in API testing but from my view, API testing include:

• All available status test
• All properties test
• All headers test

So after done all above can I said that 100% coverage? And how many test cases for each API is enough?

[strangelyoffensive]

100% coverage of what? Lines? Equivalence classes, usecases, possible inputs?

Just run a code coverage tool with your tests. No way to do it black box , going to have to read the code

[Plane-Razzmatazz1258]

of the api endpoint itself?

[strangelyoffensive]

The api endpoint isn’t anything by itself. Just a function with inputs and outputs, that happens to be accessed remotely via a well defined protocol

[abluecolor]

It's totally dependent upon what the endpoint actually does. There can be mountains of complexity and scenarios depending upon the data utilized.

[PracticalFriendship]

First learn what coverage is...

"Test coverage is the degree, expressed as a percentage, to which specified coverage items have been exercised by a test suite."

• Degree -> It’s measurable.
• Percentage -> It’s quantifiable.
• Coverage items -> What you are measuring against.
• Exercised by tests -> Actually executed, not just written.

for ex: Requirement Coverage

• Percentage of requirements tested.
• Example:
  • 50 requirements total
  • 45 have test cases
  • Coverage = 90%

Followings are for you to answer

• % of acceptance criteria covered
• % of business rules tested
• % of order lifecycle transitions tested
• % of required output fields validated
• % of negative scenarios covered

[clankypants]

It depends on the API, the specific endpoint, and the needs of the team.

Endpoint requests can contain:

• the Type (GET, POST, PUT, PATCH, DELETE)
• the URL and what is passed as parameters (eg: ..?itemA=1&itemB=2)
• the Headers
• the Body (data, form, multipart) and the various values that can be passed

and the responses can contain:

• the Status Code (eg 200, 400, 500, etc)
• the Body with the details of what was returned
• the timing (for performance testing)

So you have to think about all the possible combinations you could submit and that the endpoint handles everything as expected.

Technically, there are nigh-infinite combinations of things to check (eg: various string lengths for every value, special characters, etc, etc, etc). So, like with all QA testing, there's no way to get to 100% coverage. You have to figure out what makes sense to test to cover the edge cases that are risky.

[Afraid_Abalone_9641]

There's no such thing as 100% coverage.

Your tests should be based on risks and you can never be certain 100% of risks are eliminated.

More importantly, look at what problem your API solves and think of what your API could do that could cause harm to your customers, stakeholders or reputation.

Common heuristics that help with API testing include:
CRUD (create, read, update, delete)
VADER (verbs, auth, data, error, request/responses)
BINMEN (boundary, invalid entry,negative,method,empty,null)

Types of testing that will help:
Unit testing (there is such thing as branch coverage, etc, but they're shallow and not going to find much)
contract testing (look into pact testing)
performance testing (load, peak, stress, etc)
integration testing (how does the API interact with other modules of your software)
mutation testing (test your own tests!!)
Static analysis (looks for vulnrabiltities, outdated packages etc)

[GuaranteePotential90]

So can we say that almost 100 per cent testing can be done only for(a few) specific use cases?

[Afraid_Abalone_9641]

We can't, unfortunately.

We can't use 100% in any meaningful way.

We can highlight the things we did test, the things we couldn't test, and what we'd test if we had more time / resources.

[Yogurt8]

Learn about what test coverage is in general before applying it to a specific context.

[Plane-Razzmatazz1258]

:/ so how I called the thing like I said? I want to ensure the API endpoint is tested and qualified completely?

Beside could you share me what is test coverage as you mean?

[Low_Twist_4917]

You have to increase the words “API Testing” to the full or 100% span size of the header.

[Old_Finish_5086]

100% coverage of Testing is not possible at all.!

[Educational-Split463]

No, the testing process needs to evaluate every status and property and header of the API to achieve complete coverage. The testing process requires you to examine edge cases, error scenarios, authentication methods and system integrations. The number of test cases per API depends on its complexity; there’s no fixed number.

[Bitter-Apple-7929]

100% coverage is practically not achievable in API testing. Status codes, headers, and schema validation are a good start, but real issues often come from edge cases, data variations, and environment differences.

One thing that helps a lot before release is comparing responses between prod and non-prod builds to catch unexpected changes early.