We've been using Cypress at work and we (well, at least I) have a love-hate relationship with it.
Coming from Capybara in Rails, it is a very noticeable improvement.
Unlike others here, we never really had issues with the chaining. We don't mess too much with custom commands. We just have a library of about 30-40 small helper functions, mostly to do simple steps to test UI elements from Material UI, React Select, etc.
So, for example, if we need to select something with React Select, it can get tricky. It is a multi-step process with Cypress to ensure the thing is actually rendered. But after we do that once, it is only a matter of making a `selectDropdownOption(tag: string, option: string)` helper function. We have dozens of tests that are just 3 or 4 lines of those helper functions.
One of the major drawbacks we have with Cypress, though, is about the data. Since Cypress just uses your `localhost`, it uses whatever DB you are connected. I really miss the Capybara/Rails integration of just spinning up a proper test DB, seeding it and then destroying it after the tests were done.
I bet there are ways to do this with Cypress, but it is just not as straightforward as it was in Rails.
Not sure what you mean by "just uses your localhost".
I recently set up Cypress for the app I'm working on, which is a legacy MEAN app that I've been modernizing (migrating to React+TS, etc).
It already had a set of Express server API "unit tests" that were really more like integration tests, using `supertest` to load the Express app and make calls to the real API endpoints. I updated it a few months back to use `mongodb-memory-server` to spin up a dynamic `mongod` instance solely for the test sequence.
When I set up Cypress, I was also able to use `mongodb-memory-server`. I configured the app to check for an environment variable indicating an E2E test environment, had it connect to the in-memory `mongod` instance, and used a Cypress task to seed the DB before every test. Seemed fairly straightforward, and is working pretty well.
Coming from Capybara in Rails, it is a very noticeable improvement.
Unlike others here, we never really had issues with the chaining. We don't mess too much with custom commands. We just have a library of about 30-40 small helper functions, mostly to do simple steps to test UI elements from Material UI, React Select, etc.
So, for example, if we need to select something with React Select, it can get tricky. It is a multi-step process with Cypress to ensure the thing is actually rendered. But after we do that once, it is only a matter of making a `selectDropdownOption(tag: string, option: string)` helper function. We have dozens of tests that are just 3 or 4 lines of those helper functions.
One of the major drawbacks we have with Cypress, though, is about the data. Since Cypress just uses your `localhost`, it uses whatever DB you are connected. I really miss the Capybara/Rails integration of just spinning up a proper test DB, seeding it and then destroying it after the tests were done.
I bet there are ways to do this with Cypress, but it is just not as straightforward as it was in Rails.