Automated End-To-End-Testing: Generate API calls via swagger or make them hardcoded?
morde last edited by
We, the test automation team, are currently implementing end to end tests. We use the API of the backend team for the setup of the end to end tests, which run via UI.
Should we use the swagger file to generate the API calls or make them hardcoded? If we use the swagger file to autogenerate them, we would never know if the API changed at all, and we wouldn't have to worry about possible changes, as it always autogenerate.
But if we would know that it changes, as our setup would fail, we could also inform the frontend team about those changes, so that we could tell them: did you check if you also updated your frontend for the API changes?
What should we do?
But if we would know that it changes, as our setup would fail, we could also inform the frontend team about those changes
A break change in a Provider is responsibility of the service team, not the Consumer team (in this case, an frontend app).
When a service make a change, it should looking in the Consumer contracts it fulfilled before and check if the change causes a crash. If the change needs to be performed, the two teams should come together to solve the issue: All of this before integration of the changed Provider.
The responsibility of the Consumer teams is only keep a comprehensive contract with its Providers.
Given that, you shouldn't need to dismiss the robustness of the E2E in order to get information that you can find otherwise.