Single page application (SPA) testing

Sounds like, if state is not url-driven, you might want to expose whatever controls the Step to cypress, in an "app action" style: https://applitools.com/blog/page-objects-app-actions-cypress/

@User something else to keep in mind is that e2e is about testing a "user journey", i.e. simulating how a user would use the application. since there's no way to get to the payment page directly, a user wouldn't be able to do it, so it's not really part of the user journey. for example if you only tested the payment step then your tests may pass, but the app may fail in production if the state in the shopping cart causes a bug that breaks the payment step. with that being said: if you're able to push this down the road a little bit, i think what you may want here is a component test -- in that way you're testing a "page" in isolation given some permutations of input/state that would result from the delivery "page". in cypress v10 we're introducing component tests as a first class citizen. you would simply replace your

visit

with a new

mount

function, and pass in your form component with props. the rest of the API (assertions, spying, etc) is exactly the same. in this example you would still want e2e tests for the checkout workflow, but being able to test a "page" in isolation and asserting it functions properly given various permutations of state means you could (probably, depending on your app) reduce the number of e2e tests, which would also greatly speed up your test suite

> since there's no way to get to the payment page directly, a user wouldn't be able to do it That's true - setting up data via API requests for session will allow such thing for being possible. > you would still want e2e tests for the checkout workflow For this one I'm doubtful. If my component tests also check the state of the application (what must be filled in session - then why should I also do e2e tests? It would be similar to say that every e2e test must start with UI login test (to know for sure login won't skip any data that will break other forms) - Wouldn't you agree? (edit) in the end of each view there are also tests that navigate to possible next steps (check cookies & state of the session) - if everything is ok, I'm confident that page won't break anything in next steps. (please correct me if my understanding here is incorrect) > is actually available now (though is still in an alpha state in v9) I'll check it out, thanks!

i'd agree with that -- starting with the UI login every time may not make sense, though that would depend on a particular application's use case. typically for a component test you don't actually make network requests so the component could be tested in isolation. for example, you could stub the requests and assert that the stub was called n times. in principle, you'll know deterministically that given a certain state, performing a set of actions result in an expected end state. however, you'll still want to make sure the flow actually works e2e, for example to test that the contracts with your back-end still hold up. you could reduce the footprint of those e2e tests though. if your component tests are testing the happy and non-happy path (various permutations of state/input/stubbed responses), you wouldn't need that in your e2e test -- your e2e test would just be the happy path. this is all just my opinion in a broad sense and is not meant to be prescriptive -- if a developer decides that using the component testing functionality to do some of their e2e tests makes sense, there's nothing inherently "bad" about it. at the end of the day, there's a near infinite amount of ways an application might work, so ultimately it's up to the developer to do what makes sense for their particular situation.