Mock all Cypress requests

[0xApotheosis]

Note: Please see the discussion below about using cypress-autorecord - this is now the preferred approach.

Overview

For our Cypress tests, we currently mock only the data that is required by the UI elements and flows that we actually test.

We don't, however, mock the remaining calls, which slows down our test runs.

Reference

See the current mocks for external requests (those services not managed by ShapeShift), and internal requests (those that ShapeShift are responsible for) as an example of what we are looking to extend.

To find out what requests Cypress is currently making, we can run Cypress locally using yarn test:cypress, which will launch a local Cypress runner. Run the tests with Electron, and monitor the network tab for requests.

Examples of requests to mock:

• CoinGecko API, e.g. https://api.coingecko.com/api/*
• Yearn Finance API
• GitHack

Note, running Cypress locally requires web to be running locally - please see the README for instructions on doing this.

Some of the responses from these requests are large - the bounty hunter should use their discretion by only including data that is actually used by ShapeShift Web. We want to avoid having unnecessarily large mock data files in the codebase, and also avoid the illusion of precision that these mock files might give. The responses to these requests are out of our control, and could change at any time - only mocking the data we use is one way to mitigate the risk of mock data becoming stale.

No-opping requests that we don't need in the test environment is ok.

To keep this work decoupled from the test-related mock data, we probably want to have a new set a new set of Cypress commands, mockExternalEnvironmentRequests, and mockInternalEnvironmentRequests (or similar - use own discretion). There will likely sit in their own helper file in the cypress/support directory.

Acceptance Criteria

• All Cypress requests that occur whilst running the current test suite are mocked
• Only data that is used by web and Cypress is mocked - i.e. excessively large mock files are avoided
• We continue to use the factory pattern in cypress/factories for new mock data
• Code is extensible as we continue to mock additional services in the future, as needed
• Each stub should be given an alias, e.g. cy.intercept('GET', 'some-url', { responseKey: 'responseValue' }).as('someAlias')
• The new mocks should be used in existing tests

Screenshots/Mockups

In the example below, only the request with the alias getChainLinkData is mocked - in the resulting PR, we want to mock the rest.

Ownership

• [X] If my bounty needs engineering or needs product I have added the respective labels on the right
• [X] As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 2750.0 FOX (893.94 USD @ $0.33/FOX) attached to it as part of the ShapeShift fund.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
  • Want to chip in? Add your own contribution here.
  • Questions? Checkout Gitcoin Help or the Gitcoin's Discord
  • $4,602,451.39 more funded OSS Work available on the Gitcoin Issue Explorer

[0xean]

@bernardstanislas - Looking forward to your contributions here! Would you be able to give an expected timeline for your PR? TY.

[Bernardstanislas]

I think I'll be able to send you a first draft by the end of the week if that suits you?

[0xean]

Sounds great, thanks for the update.

[0xApotheosis]

Thanks @Bernardstanislas - please add me as a reviewer to your PR once you're ready.

[Bernardstanislas]

I just started to look at the number of external calls, I am wondering about the cost of maintaining the mocks in the future.

I know vcr from the ruby world, which records external calls and then can replay them as mocks. I searched if there was an equivalent for Cypress and I came across this https://github.com/Nanciee/cypress-autorecord

What are your thoughts about doing it this way? I think it will be easier to maintain in the future and more accurate in terms of sticking to the reality if you put in place a policy of mock updates, let's say every week.

[0xApotheosis]

This could work @Bernardstanislas. I'll take a moment to review Cypress Autorecord, it could indeed be a better long-term approach.

Thanks for the initiative!

[0xApotheosis]

@Bernardstanislas this approach sounds reasonable. Some thoughts on the implementation:

• We'll need the ability to "freeze" certain responses (or override them), as some tests depend on this data staying the same. If they are not frozen, we'd need to update the expected values in the UI every time the responses are refreshed. It does look like this can be handled by cy.route() in the test itself, so we are probably good, you'll just need to provide an example of this override (and likely use it for any current tests that require it).
• I'm conscious that we'll only be able to intercept XMLHttpRequests, but that is a known limitation of using cy.route(). There will still be some fetch requests that'll still require manual mocking.
• Another concern is that we may end up with a huge set of test data in the codebase (some of the responses we get are quite large). It's less of an issue as it'll never be manually touched, though it's something to consider.
• Please update the README with best practices for using this tool and a suggested approach for updating the mocks moving forward.

With all of this in mind, this sounds good to me.

[Bernardstanislas]

Ok @0xApotheosis this is clear to me. Unfortunately I think I won't have time to work on this in the coming weeks, I'm sorry I hadn't planned that I would be kept busy with my current job on my free time. Feel free to remove me from the Gitcoin plateform. Sorry again

[0xApotheosis]

Thanks for the update @Bernardstanislas, we've removed you from the bounty.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Workers have applied to start work.

These users each claimed they can complete the work by 264 years, 7 months from now. Please review their action plans below:

1) ezhimakov has applied to start work _(Funders only: approve worker | reject worker)_.

i'll try to mock all requests on my local server and send a PR 2) visitskyworld has applied to start work _(Funders only: approve worker | reject worker)_.

I can work on this bounty and will mock all cypress request using cypress.intercept()

Learn more on the Gitcoin Issue Details page.

[0xApotheosis]

@codinglittlecat I didn't have time to update the bounty description after the conversation above re: using cypress-autorecord to auto-capture responses.

Could you please use this in your solution?

[0xApotheosis]

Hey @codinglittlecat, could you please confirm if you've seen this?

[codinglittlecat]

@0xApotheosis , I will use cypress-autorecord to auto-capture.

[0xApotheosis]

@0xApotheosis , I will use cypress-autorecord to auto-capture.

Thank you, ser.

[codinglittlecat]

@0xApotheosis Should I remove existing mocks and interceptions?

[0xApotheosis]

@codinglittlecat some mocks are designed to exert specific behaviour in the UX, which is tested by Cypress. These mocks need to stay, and override the auto-generated mocks.

Basically, if you remove a hard coded mock and a Cypress test breaks, you'll need to keep it. The rest can go.

[codinglittlecat]

Thanks. If we use cypress-autorecord, we don't need to mock all data and intercepts. I am not sure some of accpetnace of creteria is needed. e.g.

Each stub should be given an alias, e.g. cy.intercept('GET', 'some-url', { responseKey: 'responseValue' }).as('someAlias')

[0xApotheosis]

Indeed - acknowledging that the AC is a little bit off now, we'll be pragmatic about this so long as the solution meets cypress-autorecord best practices and is aligned with the intent of the bounty 👌

Feel free to reach out to me on Discord to chat through any clarifications or questions as you go.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work for 2750.0 FOX (758.93 USD @ $0.28/FOX) has been submitted by:

1. @codinglittlecat

@0xean please take a look at the submitted work:

• PR by @codinglittlecat

---

• Learn more on the Gitcoin Issue Details page
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin's Discord
• $4,738,925.32 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

The funding of 2750.0 FOX (903.49 USD @ $0.33/FOX) attached to this issue has been cancelled by the bounty submitter

• Questions? Checkout Gitcoin Help or the Gitcoin's Discord
• $5,379,554.84 more funded OSS Work available on the Gitcoin Issue Explorer

[0xean]

@purelycrickets - to bounty