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.

    2)

    • seperating api tests
    • mocking api calls in UI testing

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

    3)

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

    what is your suggestion?



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




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2