1. Do Gleb's course, it is next level. 2. I am guessing you mean "Working with APIs from a UI application perspective" . Yes, if you're stubbing the network and isolating tests to the UI you simply update the mock data. @sparse-piano-30763 coined a term for this: ui(component)-integration testing, with some examples in his book https://github.com/NoriSte/ui-testing-best-practices#9-real-life-examples. The backend, or the parts of it you care about, should be changing at a much slower rate, so these tests are low maintenance, fast, and high confidence. You may use json, or you may use some internal utilities that generate the data . For example we have a utility that creates auth strings which we use for a fake login, and others that are factories which create objects we need in our domain (got written for unit testing initially, and works great for ui-integration as well).

cy.intercept

can take an object vs a json fixture, so this way it would be even less effort to maintain ui-integration tests. This doesn't mean you forego ui-e2e tests entirely. We don't get to do naive UI e2e before there is confidence that the backend and the front end work in isolation. For example, instead of hitting the backend from the UI tests using cy.request (great for seeding data, but not great for testing the backend from the UI) it is better to use an API test client, closer to the backend code and deployments, vs our late UI e2e. At that point we need to be careful with test duplication, use minimal UI e2e & only fill in the gaps.