Well, using intercepts and fixtures is basically i...
# best-practicesc
cuddly-stone-46263
04/06/2022, 6:23 PMWell, using intercepts and fixtures is basically instantaneous vs having to wait to query the db.
n
narrow-journalist-67230
04/06/2022, 6:29 PMI 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 PMYes, that is the trade-off. You are no longer performing full integration testing, just focusing on the UI
cuddly-stone-46263
04/06/2022, 6:35 PMAnd 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)
cuddly-stone-46263
04/06/2022, 6:36 PMRather than trying to re-create the scenario that would produce the set of data you are trying to test.
cuddly-stone-46263
04/06/2022, 6:36 PME.g. I used fixtures to test how the UI displays when there are no search results vs. many results
cuddly-stone-46263
04/06/2022, 6:38 PMSomeone 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 PMOk cool. Thanks for further information on this. Will take that and experiment with it a bit.
4 Views