https://cypress.io logo
#e2e-testing
Title
# e2e-testing
i

icy-airplane-66230

02/01/2022, 9:00 AM
Single page application (SPA) testing
Hello Cypress strongly recommends building all your tests based on view's. (one view = one test.spec.js) - and I totally agree with this. While this is great for pages that have URL that changes - it is pain for the Single Page Applications (SPA-s) where URL is unchanged. Let's take the Shopping cart example. You have 4 steps: 1. Shopping cart preview 2. Delivery 3. Payment 4. Summary How can you do the tests for payment view, if page URL is not changing & its single page application. For not single page application it is easy - manage data in session > navigate to correct page = success. My question is - How should I write tests on SPA for different views - so I wouldn't have to walk through whole process?
w

wonderful-match-15836

02/01/2022, 3:00 PM
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/
An example might be, in your app code, check for
window.Cypress
and if it's
true
add your store to the
window
object as well, then in your test you can call your store's actions to set up the cart directly, in the way that gets it to the step you want to test.
f

fancy-match-96032

02/01/2022, 3:24 PM
@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
if you're interested in playing with it, component testing is actually available now (though is still in an alpha state in v9) https://docs.cypress.io/guides/component-testing/introduction
i

icy-airplane-66230

02/02/2022, 9:35 AM
> 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!
f

fancy-match-96032

02/03/2022, 1:58 PM
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.
2 Views