Extremely biased of course :) But here's where I see the advantages of Reflect vs. Cypress:
- Cypress has a really nice local development experience that feels at home to front-end devs. I would describe Reflect as a nice remote recording experience that simulates an end-user. So we're kind of attacking the same problem from a different perspective. You can technically record Reflect tests against your local env with ngrok, but Cypress is certainly a better local testing experience. So advantage Cypress here.
- There are actions like interacting with iframes, drag and drop, links that open a new window, and file uploads that range from difficult to almost impossible to do in Cypress. We support these actions out-of-the-box.
- Similarly if you want to do visual testing in Cypress you'll need to integrate with a third-party visual testing tool like Percy or Applitools. We have visual testing support built-in.
- I've seen folks struggle bridging the gap between using Cypress for local testing and actually getting it set up in their build/deployment pipeline. Since we're a fully managed service it's just a single API call to get Reflect in your CI/CD. We also have built-in scheduling so if you just wanted to run your tests at a fixed schedule you don't need to integrate with anything, which I think is a nice way to ge t going quickly and prove out our tool.
- Because of Cypress's design, it's not so easy to get Cypress tests to run in parallel. This is really important because E2E tests take way longer to run vs. unit and integration tests, and the best lever IMO for reducing this is parallelization. This is also another tripping point for folks getting Cypress set up in CI/CD.
- The final differentiator I'll mention is really the difference between a code-based vs. codeless approach. We're trying to reduce the time it takes to create and maintain tests and we think the way to do that is to basically handle as much as we can automatically on your behalf. Instead of writing code that simulates actions, you just record your actions and we generate the automation for you. So for a flow like adding to cart or user registration, you might only take you a few minutes to set that up in Reflect but it'd be a lot longer to do in Cypress. Certainly as your test suite grows things like reusability become really important, and we support that as well. This also means that non-developers like QA testers w/o dev experience, PMs, designers, and customer support can write and maintain tests.
> - Because of Cypress's design, it's not so easy to get Cypress tests to run in parallel.
I am not sure why you think Cypress is hard to parallelize but if you don't like their managed service (dashboard) you can use https://github.com/agoldis/sorry-cypress - it's quite possible to do.
(All the rest of what you wrote sounds solid - good luck again :])
- Cypress has a really nice local development experience that feels at home to front-end devs. I would describe Reflect as a nice remote recording experience that simulates an end-user. So we're kind of attacking the same problem from a different perspective. You can technically record Reflect tests against your local env with ngrok, but Cypress is certainly a better local testing experience. So advantage Cypress here.
- There are actions like interacting with iframes, drag and drop, links that open a new window, and file uploads that range from difficult to almost impossible to do in Cypress. We support these actions out-of-the-box.
- Similarly if you want to do visual testing in Cypress you'll need to integrate with a third-party visual testing tool like Percy or Applitools. We have visual testing support built-in.
- I've seen folks struggle bridging the gap between using Cypress for local testing and actually getting it set up in their build/deployment pipeline. Since we're a fully managed service it's just a single API call to get Reflect in your CI/CD. We also have built-in scheduling so if you just wanted to run your tests at a fixed schedule you don't need to integrate with anything, which I think is a nice way to ge t going quickly and prove out our tool.
- Because of Cypress's design, it's not so easy to get Cypress tests to run in parallel. This is really important because E2E tests take way longer to run vs. unit and integration tests, and the best lever IMO for reducing this is parallelization. This is also another tripping point for folks getting Cypress set up in CI/CD.
- The final differentiator I'll mention is really the difference between a code-based vs. codeless approach. We're trying to reduce the time it takes to create and maintain tests and we think the way to do that is to basically handle as much as we can automatically on your behalf. Instead of writing code that simulates actions, you just record your actions and we generate the automation for you. So for a flow like adding to cart or user registration, you might only take you a few minutes to set that up in Reflect but it'd be a lot longer to do in Cypress. Certainly as your test suite grows things like reusability become really important, and we support that as well. This also means that non-developers like QA testers w/o dev experience, PMs, designers, and customer support can write and maintain tests.