https://cypress.io logo
#best-practices
Title
# best-practices
c

cuddly-stone-46263

04/06/2022, 6:23 PM
Well, using intercepts and fixtures is basically instantaneous vs having to wait to query the db.
n

narrow-journalist-67230

04/06/2022, 6:29 PM
I am not as familiar with intercepts and fixtures so I will have to read up on that some more. I am under the impression though that you would be removing a layer from the 'end-to-end' aspect though if you don't allow the calls to hit the db. Or is it more like this? 1. Navigate to a Search screen in app 2. input filter criteria that should return your test data 3. Intercept the request / search, and force your data to come back (never hit db) 4. Click to open search result 5. Intercept the request / load data call to force your data to load (never hit db) 6. Manipulate the loaded info via the UI (your test steps) 7. Perform action in the UI (ie. Save) 8. Allow the Save to go through?
c

cuddly-stone-46263

04/06/2022, 6:34 PM
Yes, that is the trade-off. You are no longer performing full integration testing, just focusing on the UI
And yes, you could follow the steps you listed, I believe. The advantage is you can test different scenarios much faster using fixtures (pre-supplied data)
Rather than trying to re-create the scenario that would produce the set of data you are trying to test.
E.g. I used fixtures to test how the UI displays when there are no search results vs. many results
Someone else had mentioned that you should test regularly the happy path and use fixtures for edge cases
n

narrow-journalist-67230

04/06/2022, 6:59 PM
Ok cool. Thanks for further information on this. Will take that and experiment with it a bit.
4 Views