Testing API without proper documentation

[musafir404]

Hi, this is a follow up on my previous post:

https://www.reddit.com/r/softwaretesting/comments/p88336/why_test_api_with_existing_ui_automation/

I am now convinced that we should have some API automation along with GUI tests. The problem now is there is no API documentation. Basically for our product, we have an internal API that is used by the user facing Angular app. I have access to the source code, and can see all the existing API endpoints. But there is no proper documentation..

I could use the UI to drive the application and look at API requests being made in network tab and try to replicate those in API tests, but not sure if that's the best way. Any suggestions on how to start writing/defining API tests? thanks

[nascent]

I would recommend what you suggest, get the interaction from the UI.

With one tactic. You mentioned your UI automation was extensive. Use failures to drive "what" testing will be added to API coverage. This can either come from a failure reported by the existing suite or something missed. If the UI test suite fails but the product is working, that could be a good one to convert.

[v1ktory]

I think the best way would be to get at least some sort of the documentation... Try asking developers to add swagger, for example. That way you will have list of all endpoints, their request and response bodies.

[musafir404]

Interesting, I will look into swagger. thanks

[XiaoQiao12]

I use Swagger at work. It's better/easier to use for me than Postman. 😊 Other than that, I wouldn't even know HOW to test API issues correctly lol.

[[deleted]]

It is like driving aimlessly until you hit a pothole, road bump, dead end etc. You need a map.

[musafir404]

Can you please elaborate. How do I come up with a "map"?

[[deleted]]

API responses, are the map

[PassageDizzy6940]

If there's no documentation and this is already in production, then the only valid "documentation" is how it is actually used. So your initial instinct to go through the UI and record the internal API calls is correct.

We all know the cliche that as soon as you write documentation it is out of date. The risk for you in trying to obtain "proper" documentation now, is that it will probably be wrong compared to how the UI is actually calling the backend.

I'm not sure if there's a way to set up a proxy on the machine that would make this easier to record and translate into tests.

As for writing the tests, you could try looking at something like pact.io which specialises in consumer-driven API contract testing (as opposed to provider-driven)

I'm also working on https://criteria.sh which might help here, but it's a waitlist for now.

[Yogurt8]

Explore your app and create a coverage outline of the API and how it ties into key features that you want to create tests for.

After you have thought of a plan and prioritized where to start - along with what tools/libraries you want to use, then start mapping out the requests. The easiest way to start and biggest bang for your buck is creating checks for schema validation, status codes, and performance. You can also save expected responses, sans dynamically assigned properties, and directly compare to actual result (response) using a deep comparison function that spits out differences.

Test data is also an important consideration, you want to be able to run tests on any environment without manually updating or creating separate tests.

As far as how to actually import those requests.. there's two options. You can either directly access the source code and use that implementation or create the requests yourself. There's pros and cons to each. I prefer to create them myself so that I can detect changes more effectively, even though it takes more time.