Cypress: Fast, easy, and reliable testing for anything that runs in a browser
cypress.io
cypress.io
It’s been a few months since I’ve touched it, so I’m struggling to give more specific criticisms.
I’ve had a really great time using Kent Dodd’s DOM Testing Library [1] for unit tests. The readability and writability of these tests has been fantastic. I wish I could use the exact same API for e2e tests. It looks like they actually do have a Cypress version of the Testing Library [2], but it seems to suffer from the same Cypress-isms that I was just complaining about.
Has anyone else had a similar experience? It seems like I’m in the minority opinion. Maybe I’m just bothered because I don’t understand Cypress well.
[1]: https://testing-library.com/docs/dom-testing-library/intro
[2]: https://testing-library.com/docs/cypress-testing-library/int...
This even model is sooo confusing, clumsy and error-prone that writing any non-trivial test is a challenge. Whole product uses async/await or Promises and suddenly you have to switch to this baroque model just to write a test. Reusing logic between production code and tests is pretty much impossible.
Dynamic pages etc. often confuse cypress. I'm actually not a frontend developer, so I don't have a lot of insight while exactly that is, but I just know that it has been a huge drag.
Other than that, it would be OKish. Being able to test the UI is great, but I would advice everyone not to base the whole testing strategy on it. It's just too heavy, slow and unreliable. It doesn't not scale even moderately with the product growing.
e2e testing is better done on API level, IMO. You'll want redesigns, changes of UX, and suddenly your changes will require updating tests, which otherwise (if done on the API level) would require no modifications.
Of course if the functionality changed (like you split something up into 2 pages) yeah you need to update your UI tests cause you are testing a different experience now. But they are UI tests, so yeah. That’s appropriate.
I dunno. It sounds like you found other parts of it unwieldy as well, but the idea that the tests are inherently brittle is wrong. Time spent maintaining UI based testing is saved many times over when compared with the manual clicking around that it saves imo.
I've used cypress at work but have suspended it since we used it end-to-end and it clogged up backend databases.
How often website redesigns are only about html? Usually everything changes. New flows, new dialogs, new toolbars, new frameworks.
Often the web UI gets and Android UI and iOS UI siblings. Gets replaced altogether by a completely different UI, developed by a different team.
APIs change much less often, and can be shared between many UIs. You can also version them. How are you going to version a web UI? Like reddit with "turn back on classic look"? How long can you keep the old UI around just because you have 1000s tests around that use it.
> but the idea that the tests are inherently brittle is wrong
I don't think so. Tests are great calcifyiers (check my blogpost about it if you want). If you test though your UI, you're calcifying your UI. The more you test though it, the more you calcifying it. No way around it.
If you are wholesale redesigning/rebuilding a whole site and all the workflows yes of course you need new tests. But also your users would get pretty impatient if entire ways of working are changing all the time in a way that makes testing a giant moving target.
The purpose of a UI test in my mind is to make sure that the core business things a user is supposed to be able to do, are doable. In the context of your blog posts, I think those things should be calcified.
Like, I want a test to fail if I remove a workflow that used to be there. I want a test to fail if a form field suddenly has no label. There should be those alerts when functionality that was previously understood to be correct has been changed. Lightweight UI tests with some easily re-approved screenshot diffs goes a long way.
Having said that, I find parts of it v confusing (although not the asyn stuff) especially around assertions - there seem to be multiple ways to do things and I'm never clear which is which.
As a sibling reply said, try to write cypress (or other similar product) tests not to rely too much on layout - I use html data attrivutes rather than text or Dom based selectors, so the tests can survive most redesigns, and if they don't, it's because the user journey has changed enough that we _should_ be changing the tests.
Nothing wrong with async code; but it's often sold as the "obvious" solution to, well, several things happening and some of them taking long - and it's just not that great a solution.
I tend to think of them clicking things and waiting for a response then moving on to the next thing when that happens (or failing the test when it doesn't) which seems to fit well with an async model.
Cypress _does_ do a lot of magic behind the scenes to stop you explicitly using async/await or promises in the code... Which occasionally bites it.
Especially when you have to use a .then to use values you pull from the Dom.
In fact, if you want to minimize the chance of deadlocks, using threads or processes for every action is safest; although of course that means you may get issues with concurrent modification. But though that risk is serious, it's worth noting that async code doesn't actually solve it; after all, every await may mean a context switch, and thus if you have shared mutable state living across an await, all bets are still off. async-only code with exactly 1 thread only provides safety to the extent that modification is encapsulated and that the module within which the internal datastructures are updated does not use async. And that's not nothing; it's kind of as if a java object was synchronized on all methods. But it's also not reliable enough that you can just forget about concurrent modification, either.
But if all you want to do is automate a browser, those overheads are completely irrelevant, and this story about concurrent modification likely is too. You could use either model equally well. To be explicit: there's nothing about promises that means you need to use async. It's only once you start chaining a bunch of them that you enter async territory, but why would you ever do that in a threaded model when automating a browser? The browser is so heavy weight, just fork a bunch of processes already, and KISS: no need to worry about any of this, at all.
The programming model is very odd. I found it next to impossible to share any code between tests, and most of the programming skills I've learned over the decades didn't seem to apply.
It is vastly superior to anything else we've seen in stability and polish. If I only could write reasonable code for it, things would be great...
And... I just couldn't figure out a way!
That said, I find checking for specific values in the page against other page values to be really difficult so if you're doing that with the table... good luck!
If you want to test the backend on its own, I personally would recommend using a different framework than cypress (or a different framework than the one being used for frontend e2e testing in general). Otherwise you risk that people conflate these two things and start "testing the backend" in e2e-tests for the frontend, which are super slow.
Cypress is a recent addition for us, so this is more a curiousity than anything else. I've done similar fully e2e / functional tests with puppeteer in the past.
I haven't had much time to try anything yet, but cypress's override of promises and async / await makes me think it'll be a pain to try adding non-cypress-specific checks to a cypress test.
You use Cypress to do something on the frontend, which triggers something on the backend and ideally that change is reflected on the frontend, you test that frontend change using Cypress.
For backend testing just directly call the backend API's and then check the database directly.
Cypress for the simple tests, and for the more complex case, e.g. opening tabs, testing your SSO login paths, I frame widgets, you end up using Playwright. I spend quite a lot of time to even fork Cypress to add support for testing WebKit browsers. Probably was quicker to write a Cypress kind of solution for Puppeteer/Playwright
We run integration tests with Cypress and then rspec or some other Rails testing platform for the backend.
Cypress uses fixtures so ideally you would not let it hit a backend API unless you don't care about reproducibility of the response. For example a PUT will augment the data on the backend so when you run the test again the backend data will probably give you a different response to assert and fail your expected.
Most of the other open source tools (not to mention enterprise tools like Testim.io where I work) support the things that make Cypress "fast" like mocking network requests or automatically waiting for elements. I wrote an article about this somewhere I can dig it if you want.
If you have data showing differently I'd love to see it.
But yes, when we tried to run with the patterns they advertise, the tests became indeed hard to write and read; maybe we did it all wrong but it's at least consistent with the experience expressed by you and others in the thread here.
Which is fine when the page object is a login form, but a bit more comfortable complicated when it's notification 5 or something.
get root() {
// It is important here to run cy.get()
// each time this property is accessed.
// Lots of methods of this class chain
// off of `this.root` so it needs to be
// re-evaluated every time.
return cy.get(rootComponentCss);
}
find(selector: string, options?: any) {
return this.root.find(selector, options);
}
get sendMissileAlertButton() {
this.root.find('.x-hawaii-missile-incoming');
}
And in tests, you can just do:
tester.root.find('select.foo').select('hoge');
tester.sendMissileAlertButton.click();
``` Cypress.Commands.add('yourHelperName'), () => { //your code } ```
x.usernameField.type('Joe User');
x.passwordField.type('$ecureBR0');
x.enterWrongCaptcha();
cy.get('.err-captcha-fail').should('be.visible');
I don't think the Cypress docs probably do a great job emphasizing how easy this is (especially since they go out of their way to de-emphasize the 'page objects' pattern, but without offering much in the way of a replacement).
Code that is just inspecting the DOM to find elements, or to do stuff to them that is just working up to the state where you can actually test something, should be in some shared object/library, but that is as easy as:
import { Whatever } from '/foo/bar';
Their examples show using Cypress commands for pedestrian things like "log in to app" but there is no need to get all Cypress-specific for things like that.
Instead, we typically write "test helper" objects for that, which are conceptually similar to the Page Objects pattern from the Selenium era. So like:
class GroupUiTester {
get groupChooser() {
return cy.get('#group-chooser-button');
}
}
tester.groupChooser.click();
An example of "doing something weird" where we do use Cypress.Commands is like:
Cypress.Commands.add('disableDefaultLocalStorageClearing', () => {
Cypress['LocalStorage'].clear =
SUBSTITUTE_CYPRESS_CLEAR_LOCAL_STORAGE_FUNCTION;
});
But the benefits we have vs. what you experienced with Selenium IDE is:
- Instead of using an extension to record your actions, there's nothing to install to use Reflect. We spin up an instrumented browser inside a virtual machine and screenshare that with you within our web app. It records your actions and translates those actions into a repeatable test automatically.
- Since we have complete control of the test environment, we can do cool things like make recording file uploads really easy or present a nice workflow for getting coverage of visual regressions via screenshot testing.
- Our recorder is more accurate :)
- For every test you run within Reflect, you get a video synced up to the steps in your test, along with console and network logs from the test run.
- Instead of emitting Selenium code that you then maintain like a normal code-based testing tool, we are completely no-code meaning that even updating a test is completely codeless. So for example if you need to make bigger changes to an existing test, we expose a way to re-record only the portions of the test you want to change, and keep the rest as-is.
It was some time ago so I may not remember correctly but I felt like cypress was not for people already fluent in javascript, a bit like jquery but pushed even further (you need to do everything the cypress way now, you can't even use variables or promises...).
We use them on my team because they make the tests more readable and keep us from having copies of the same selectors in multiple places, but you can easily use TestCafe without them.
Also no out of the box way to run more than one instance with incognito tabs to have communication to test multi-user bugs.
Perhaps radical, but I think it should support hooks with Playwright/Puppeteer that you can hand control back and forth to as a safety valve just like being able to shell out to the command line when your favorite programming language doesn't have a library for what you need.
The difference here is that the browser context needs to be passed - that means some janky handoff (which with crypto will be a PITA) or using the Playwright/Puppeter connector under the hood.
I have used multiple other variations of test frameworks that were built on the Selenium WebDriver protocol. The official documentation [1] states that Cypress differs fundamentally and architecturally as compared to Selenium.
Admittedly I found Cypress web testing framework frustrating initially, and yes, I have performed many re-writes because Cypress documentation behind command chaining and assertion queuing to be not intuitive.
Thanks for my management's support, perseverance afforded me with the stubbornness with a purpose of checking out Cypress if it has a better DOM manipulation, how it operates directly in the browser, interactive test runner, and its API and configuration.
It required 3+ months of perseverance in getting the Cypress tests organized [2] for handling web testing core functionality of a commercial-grade corporate web site. My current layout required adding a lot of extensions to the core folders under /cypress: /support, /plugins & /config.
I am motivated in writing a series of posts on Medium, because I like Cypress. Is it perfect, no, some aspects are frustrating. In other words, I have not found a solution yet, but I will continue to use Cypress.
From the minimal amount of Cypress development experience, suggestions: a) Switch everything to TypeScript b) Declare Commands within Cypress namespace c) Understand selectors d) Add querying attributes, like 'data-cy', to expedite finding elements. e) Wait for element to appear using 'cy.get(...).contains([ element attributes]).then(...)' f) Avoid if at all possible using XPath for selectors. g) Use 'cy.wait()' to wait for an alias to become available, and not for millisecond delays. h) Use available eslint extensions for Cypress.
I will try to get a couple of posts on Medium as soon as possible. They may be helpful.
[1]: https://docs.cypress.io/guides/overview/why-cypress.html#In-... [2]: https://docs.cypress.io/guides/core-concepts/writing-and-org...
1. It saves a snapshot of the DOM state before/after each test step. If you have a long acceptance test where it's deeply navigating through your app (i.e. visit "/admin", click on "Login", type "username", click "Submit"), using the GUI test runner will show each individual step in a side-panel. From there, you can hover over a step to see a snapshot of what the page looked like before that step was executed, and a snapshot of what it looked like after.
I had previously only used test runners where, when it would run the acceptance test, you would see a series of really quick flashes of the runner executing a bunch of steps faster than my eye could track, and then a big FAILED message. What failed? How did it fail? Cypress solves this problem by saving the DOM state and allowing me to traverse backwards through the state of the app until I find where things started to go wrong.
2. The cli test runner records a video of its test runs. Super useful in CI where you don't have access to the frontend. Cypress will record its run to an MP4 and you can investigate failures after-the-fact. This has solved a lot of "it works on my machine but not in CI" problems that seem to come up pretty often.
The other positive thing I have to say about Cypress is that I've actually found it more helpful as a development sidekick tool than as a test runner. Particularly when developing features on the front-end that require a lot of user interaction, many times it's easier for me to whip up a quick Cypress test that automates the user interaction (with assertions along the way to make sure the app is working) and then use the GUI Test Runner to do all my debugging.
It's not perfect and I definitely have some frustrations with it, but on the whole it's helped my productivity quite a bit.
https://github.com/testimio/root-cause
So both those things are quite possible with open source tools.
I recently started using it in a small project and I'm really enjoying myself. I mainly use cypress for high level UI testing and I mock my sever.
I found the server mock tool (route and route2) brilliant. I find the syntax for browser commands easy (visit, click, get). Using mocha with should and chai is fine.
Anyways, apart from some minor problems (you can't select a single test to run), I really love cypress. Compared to last time I used selenium, it's such a difference. Especially that cypress just seems to be one holistic package that works. Can't say the same for selenium.
Used Selenium 1 and 2 in the past, and Cypress is definitely much easier. Can't say if the current Selenium is better though. But being able to reply the DOM states, and record videos, without needing to install other tools/libs is also very convenient.
It is not perfect but I think they have the correct idea of how web e2e tests should work and I hope they will keep improving the experience as time goes on.
Yes you can, by using it.only(): https://docs.cypress.io/guides/core-concepts/writing-and-org...
What I meant is that you can't select it via text search in the shell. But `.only` should work for me fine too!
It's an alternative to Cypress and from what I remember, it has a much better API.
Basically we took a bunch of Testim code for screenshots/console logs/network etc and made a package out of it at https://github.com/testimio/root-cause
It's amazing how much you can get done just combining open source tools together (like sauce's HAR viewer)!
We at Cypress do read these comments, and we definitely understand both the positive and negative opinions. If you have never tried Cypress yourself - take a look at the first test page https://on.cypress.io/writing-your-first-test
Try it yourself, you might like the syntax and the developer experience. And if not - no worries, there are TestCafe, Puppeteer, Playwright, Selenium, Webdriver that might work better for you.
The method chaining feels good as long as you check the return type of the function your calling. Most of the time it returns the element you just asserted against. And when you're trying to drill down into deeper sections of the DOM you can speed up tests by calling .within from a higher level element to keep the search to a specific part of the tree.
The individual steps with their state available for viewing in the sidebar is great as others have mentioned. The test doesn't run at light speed, so locally you can actually VIEW what is happening. Plus when it does fail there's typically a long timeout (~40 seconds) before the test actually fails. So it's very noticeable when your test hits a snag.
Also helper functions are not hard at all, and we have a few useful ones we use in almost every section. I have more I could say, but I'm not going to write a huge raving post. Just wanted to try to post some positive contrarian perspective.
I would much prefer to use Puppeteer or Playwright now that they’re starting to stabilize - for a while they both either didn’t support Firefox, or required custom builds of browsers.
So, I am very surprised (but interested) to hear your tale. It is literally the first time I have ever heard of somebody going back (I assume it is back?) to Selenium from Cypress.
When we used Selenium (until mid-2018) our tests were hard to write and hard to parallelize, so they took like an hour on a beefy machine. Now they take 5 minutes (across 16 medium-ish VMs, admittedly, but parallelized "for money, not for free" by the Cypress dash board service.
I'm curious to hear more about your experience moving off Cypress — did your test suites take longer to run? (Or did you perhaps move off of it before they introduced auto-parallelization?)
I'm really bad at marketing/getting the word out, and google took forever to approve the extension so I lost interest. I made it because I hate manually writing E2E tests like with Cypress.
Maybe if others show interest in it, I'll be motivated to resume the plans I had for it.
Following that up with a question, what's their business model, consulting? I didn't immediately find any upsells on their website.
Edit: finally found the pricing page, to but the core is still open source then?
The dashboard also acts as an orchestrator for parallelization. I assume the orchestration is free up to the monthly free-limit, but if it falls back to single-threaded after that I don't know.
DX is fantastic, of course, but I'd feel quite uncomfortable in committing to a commercial offering that I thought was being less than fully honest in what they were offering, just as a matter of trust.
It really is a great test runner on its own merits, though.
Each application either used the same OAuth solution that customers used or they used Okta which was more common for internal applications. It was a little unclear which was supposed to be used as some applications used the former and then it was common to have a "backend for frontend" that would solely deal with communicating between... ah, you know what, I don't even want to think about it.
Suffice it to say, the React application in question made use of the okta-react library which meant that the actual SSO dance was part of the Javascript bundle being shipped
That in itself isn't a problem but Cypress seems strongly designed around the idea that you never leave the domain. We got that to work but then when 2FA was mandated, we were kind of screwed.
We didn't have a TOTP seed to generate a passcode as part of the auth flow which is highly questionable of course but we also didn't have a solution to bypass the actual authentication step either, as it wasn't an API call to a backend (we controlled)
Anyway, we tried making a service account that has 2FA disabled only to discover that 2FA was mandated at a network level (unless you were on a specific subnet we later discovered) meaning we would just see some arbitrary "error 53"
Anyway, This isn't to say that Cypress is anyway at fault here but I have seered in my memory, from the tens of hours spend on this crap, the sight of threads where people would "How do I use this with Okta" and the developers essentially saying "Oh, yeah, you shouldn't be doing that".
Having said all that, while I remember finding Cypress pretty handy, I'm more fond of Testcafe myself :)
Ah also, I believe a lot of teams made use of a Zalenium... cluster? Bunch of instances anyway. I also recall a number of people having the above issue with no solutions
Same here with PayPal or 3d-secure. I am actually baffled by the decision - what kind of applications did they thought was going to get tested - Todo apps?
Last I checked there was GH issue and they said that it will get addressed, I hope.
What they are also saying is that it is bad practice, you should send API requests from the tests that simulate the payment, for example. I find this BS, IMO the automation tests simulate user and user would not send API requests but click buttons on the screen.
Sounds fine on paper but in our case, we called out to multiple backends, with no unifying gateway that traffic reached them through as they were owned by different teams.
Realistically, that was a discipline issue rather than a technical issue of course but I do wonder how many organisations find tools like Cypress a non-starter due to their impure set up
See the article I wrote here: https://www.testim.io/blog/puppeteer-selenium-playwright-cyp...
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.
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.
Agree with everything else though + the one time I opened an issue in their tracker (I asked a question about a crash in order to contribute!) they totally ignored me and then they opened a bunch of issues in projects I maintain and they use (not paying me, which is fair). Guess how much love I gave their issues?
Also (nearly) every command in Cypress is a promise which allows you to make them then-able. [2]
I don't agree with using Cucumber for anything. The way most teams implement Cucumber makes it such a pain to write a test. I do like the suggestion of puppeteer tho. If you haven't heard of playwright [3] I'd look into that. From the same creator as puppeteer but was hired to work on playwright full time. They have the advantage of being to test on gecko, chromium, and webkit browsers which is really nice because IME anything Apple becomes such a pain to setup to properly test.
[1] https://docs.cypress.io/api/utilities/promise.html#Syntax
Say you have happysite.com , but your using parentsite.com to authenticate, Cypress will explode instantly. If your test will ever leave your first domain, same thing.
Don't take shortcuts, use Puppeteer or it's successor Playwright
Thank you , I'll keep that in mind the next time I build a front end testing stack
cypress is great. the video recordings are very useful. the paradigm of command driven actions is nice to see step by step.
but the more time you invest you find the rough edges: xvfb and parallelization, cypress runtime crashes (vastly improved since 5.x), a sometimes top opinionated stdlib with no alternatives (cy.get errors are always fatal), and a somewhat high cost pricing model.
i understand they need to run a business but i feel like the project is one custom scheduler away from losing its value prop. the cypress website itself is actually the worst part of the entire experience
cypress for most of the complex tests. puppeteer for more basic things you don’t need to debug / “should always work”. because the debugging experience is much poorer. but the tests are “free” to execute. i’ve only wasted time in selenium and don’t recommend it for any purpose
It's a shame 4.0 has been in beta forever and people keep taking from the project and not giving back, and that async stacks got broke(but I created a proxy that creates a nested stack and preserves the original test code call site), but it works very well in general.
Cypress was officed at ATDC at Georgia Tech (now downtown), so a lot of companies and startups in metro Atlanta adopted it and helped it take off. Further, any student from GT or SPSU trying to intern through ATDC (and probably ATV) would have been at least tangentially exposed to it, meaning these new grads / young devs got exposed early enough in their careers as to be impressionable, and more likely to adopt something new. It also helps to adopt a technology when you're three doors down from the devs.
If your goal isn't to test a frontend, Cypress seems inappropriate.
I agree that the backend team should test their own stuff. End to end testing is a poor substitute for that. There may be value, though, in having some (light?) validation of a dependency, ie. the frontend team validating that the backend is still there. I heard the latest SpringOneTour talk refer to this as "enemy testing". Maybe really bad for internal teams, but I can sympathize when the dependency is external and you don't know when to expect changes.
Especially with this test runner: https://github.com/microsoft/playwright-test
It’s a tricky problem. We just started using Percy/Cypress at our company.
Compare this to testing the back-end where I can crank pages of tests like I’m the Beethoven of testing.
I love front-end dev but I cower at the thought of testing anything that’s not a pure data function or a very dumb presentational component.
1. Selectors still need to be specific enough `.button` is great until you add another button.
2. Selectors can be _too_ specific in weird ways. Recently, I encountered a bug where reformatting my markup broke a test that detected if an element was present by checking for its contained text. Turns out the newlines that I inserted between the opening and closing tags were significant for the test. Thankfully, it's all JS, so one can appropriate work around.
3. For SPAs, it's harder to convey that a page/view load has completed. So, if I click a button and the entire viewport updates (potentially downloading a JS bundle in tandem), I either need to insert timeouts of arbitrary lengths, or explicitly call out to the the provided network API hooks. This can be annoying because now I not only need to worry about what I _can_ see when I navigate through my app, but also what I can't.
It's far better than what has come before, but it's not a silver bullet.
If your flakiness is due to items like layout thrashing, or triggering other HTML re-rendering like painting or compositing, IME you'll have issues with any test runner until you fix the problems of poor browser performance and layout thrashing
If your tests are flaky due to backend calls being inconsistent or taking a long time, Cypress allows you the ability to intercept network requests [1] and return "fixtures" of what you want the data to be. The benefit of this is you can go directly to any route for your web app then just stub the data you need immediately and test against that. The benefit of this approach if you can easily test negative scenarios and how your application behaves. Negative scenarios like failing response (500 error) or having a 200 response with missing data fields. This is useful when testing something like pagination because you can make the "3rd page" fail when you trigger that API call by forcing it to give you a 500 error (or something else). The downside of this approach is that you are no longer using real services that your app relies on, but you gain some confidence on testing multiple scenarios in an easy format rather than setting up proper chaos engineering scenarios/experiments.
Other testing libraries do allow you to intercept requests as well (I know playwright does this), but one of the selling points of cypress is that you have access to the same browser APIs that you have use when doing web development.
[1] https://docs.cypress.io/guides/guides/network-requests.html#...
it has been months, and I can't remember the actual error we got intermittently, but I do remember it was something buried inside cypress (I think it was related to taking screenshots?) that caused our tests to just randomly fail sometimes.
There's a couple of annoyances still: - I hate that some things are wrapped in JQueryLike and then other times they're not. - I still hate that there's async/await magic and wish we could stop it for e2e testing and just be explicit so I know what is or isn't going to be magic.
This last project we’ve actually been running true E2E tests by spinning up the backend in GH actions (looking for a branch with the same name or falling back to master), seeding it, and making snapshot-style assertions about the UI. It’s more complex and slower but tests a lot more code now that the backend is involved as well as the API layer. It has helped a lot in major refactors.
What is the value add over puppeteer ?
I feel this is the hacker news equivalent of karma farming.
I've used most of other front-end testing tool in the past (selenium, puppeteer, playwright) and none of them support drag and drop if I remember correctly.
The tl.dr is that I didn't end up using Cypress https://www.testim.io/blog/puppeteer-selenium-playwright-cyp... but it mentions lots of pros of cypress vs. the others.