Should I separate my API tests from E2E tests

Question

I have a system that displays 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 that the correct data is represented in the UI. What should be the test strategy for this? I'm thinking of using Playwright framework.

What I have thought so far:

1. For every test case

   • making api request
   • asserting response
   • checking the values in UI

   It doesn't seem ideal.

2. • separating API tests
   • mocking API calls in UI testing

I don't know if it would give the confidence of real user experience.

3)

• separating API test
• UI only test (without validating data)
• applying no 1 for most important test cases

What is your suggestion?

Answer 1

Testing mission:

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 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.