Add migration guide from cypress fixtures to mirage about site HOT 3 OPEN

Hey @romansndlr thanks for this!

Now that miragejs.com is launched I'd like to start getting more guides like this onto the website. This is much appreciated, especially since you have a lot of Cypress experience!

I think there's a lot of power behind a guide that shows you how to move away from Cypress static fixtures and start using Mirage factories. I'm wondering if there are any Cypress tests you've written that have a lot of repetitive fixtures that are easier expressed as a factory?

Also, Sam and I have been recommending folks not use @alias's with Mirage requests because it feels like testing implementation details. Sam wrote about this here. Do you think it's ok to cut the cy.wait('@createUser') from the example?

@samselikoff Would like to get your thoughts here as well.

from site.

from site.

Hey, @ryanto @samselikoff! It is my pleasure to contribute to this wonderful tool!

About the waiting for the HTTP request, we might have a disagreement about this issue for these reasons:

• This is typically the types of assertions that cypress users have because this is encouraged by the cypress docs, so if we want to provide the easiest "least resistance" path to migrate a test file from fixtures to mirage, I do think we should keep it just to show you don't have to remove it.
• From my experience, most of the time you are not 100% covered by just asserting against the rendered output of a successful HTTP request... sometimes you need to create a user and then you are redirected to the users' list that doesn't display all the properties you passed in the request, or you need to notify the server to send out an email and you need to make sure the right data is sent.
• If we are recommending against this approach, I think we should find an alternative way to make sure the right data is sent to the server when you need it. do you guys still recommend asserting against mirage's database?
• Another thing to keep in mind is that users might want to change a test from being an integration test to an e2e test so any guide we provide should also take this into consideration.

So let me know what you guys think and then I can try and make a new draft of something more robust. maybe we can make a multistep guide that shows different levels of migration, meaning you show the smallest change you have to do and also how to take it a step forward and make a bigger change.

Thanks again for the opportunity! still waiting on that invite to the podcast though 😜

from site.