Create ability to mock server requests

kylemh commented 5 years ago

Current behavior:

As described here, Cypress doesn't have the ability to get involved with the server process as it stands - it's just about the client. In a bid to ensure that my test environment is as identical as possible to my prod environment, I find the suggestion of rendering on the client just for the sake of tests to be less than ideal.

Desired behavior:

It'd be awesome if we were provided instructions on how to make our server make requests through the same network proxy layer that Cypress works or if Cypress could provide some kind of plugin to handle that.

Versions

All

zetoke commented 5 years ago

This one actually looks as a very good idea. I got into the same problem when I need to mock some API for tests (they are not full e2e) and I also have server side rendering with Next.js So it works beautiful without SSR and I'm a bit stuck in term of how to mock SSR requests as well.

kylemh commented 5 years ago

Users of Nuxt and Next - as well as any MVC framework - will heavily benefit from something like this.

dts commented 4 years ago

Is there any way to mount cypress/server as a piece of express middleware?

Oterem commented 3 years ago

@zetoke @kylemh, did you find any feasible solution for this problem?

kylemh commented 3 years ago

No, but I think I've got an idea (if you use Next.js). Some context first:

This has never since been a big need for me, as an avid user of real data (my setup). The edge case I was trying to catch:

Using Next.js.
Using getInitialProps (SSR).
Had situations on certain endpoints that would not fail during that build, but did during the execution of a build when a user requested the page.
I made a fallback strategy, but could not add assertions to it, as I was unable to stub the responses that Next.js data fetching methods returned.

While Cypress never resolved this issue, Next.js has evolved.

I almost never use getInitialProps any longer, since I can use ISR methods which have a more assertable fallback system during development.

The idea: You can use Next.js API Routes + Polly.js (or some other tool to quickly scaffold fake responses to real requests) to create a dumb clone of your backend. You could then conditionally fetch via the dumb clone when CYPRESS_ENV is true (or however else you want to identify that Cypress is at the wheel).

The idea isn't exactly one to get excited about given all the work, but it's something.

Frankly, if you really dont want to use real data and have a lot of areas which make requests from the server during your client's creation... Cypress may not be the tool for you. If it's a few spots, consider letting Cypress take you X% of the way there and supplement it with an alternative method for the last bits.

This is probably worth more attention, since the Cypress org - by their own admission - believes a majority of your tests should be stubbing responses and tools like Next.js and Gatsby are drastically increasing in popularity. I have just been lucky enough to work at places that value integration tests with real data 🤷‍♂️ . Our suite takes longer, but we're very confident about it!

OliverJAsh commented 3 years ago

In case it helps others: we ended up using MockServer for this instead of cy.intercept.

Update:

Related Stack Overflow https://stackoverflow.com/questions/47631821/mocking-server-for-ssr-react-app-e2e-tests-with-cypress-io
https://github.com/httptoolkit/mockttp is another tool

cypress-io / cypress