Should I seperate my API tests from E2E tests
I have a system that display data it gets from API calls. There are multiple objects and every object has 7-8 properties. User is not allowed to change values and the system has a simple UI. I want to test the correct data is represented on UI. What should be the test strategy for this? I'm thinking of using Playwright framework.
What I have think so far:
1) for every test case
- making api request
- asserting response
- checking the values in UI
it doesn't seem ideal.
- seperating api tests
- mocking api calls in UI testing
i don't know if it would give the confidence of real user experience.
- seperating api test
- UI only test(without validating data)
- applying no 1 for most important test cases
what is your suggestion?
I want to test the correct data is represented on UI
The target system is the UI, so, you have to explore two aspects:
1 - Does my UI integrate correctly with the service(s)? 2 - Given that (1) holds, is the UI displaying the data correctly?
(1) can be tackled with https://pactflow.io/blog/what-is-contract-testing/ . In (2), you should have control over the inputs of your system (the UI), thus you can explore the data provided by the service(s) - this control comes from using test doubles, like mocks. Their acceptance tests and API documentation (e.g. OpenAPI) can be good source of ideas for what the services can provide.