OK.. now it's working again 🙃 the hell 🙃

Oh, it's sidebar navigation vs page navigation. That was a rollercoaster of emotions.

@User thanks for catching these broken links 🙂 fixing these asap. This was a regression I introduced end of day yesterday. EDIT: fixed.

❤️

Almost like you need... e2e testing 😏

Hello everyone, does somebody have an idea how stubbed responses (fixtures json files) can be best kept up-to-date with reality? I mean from both structural and valid-values point of view. I think stubbing in general can soon lead to situations that a given test will give false positives and the mismatch(es) in stubbed vs. real data might be left unnoticed for long time.

I've experienced this as well. To catch inconsistencies maybe you can create Cypress tests that should produce same response and do a deep compare (_.isEqual() for instance).

I haven't tried this myself though but really should. Right now fixtures can really give us false security.

I think it's a general issue, not Cypress (fixtures)-specific. But what would be the point of stubbing then if we created another test that produces the same json data like what we have in the stub (fixture)?

Speed is one reason. Faster with stubbed data.

But I hear you. I tend to move away from stubbed data as much as possible to prevent having to update fixture files.

Look for "generate stub data from schema"

Depending on your backend, you can create data specific to your endpoints.

For client-side state, I avoid json files and opt for js files that call into my real source code's factory functions/classes so that my source code shares as much as possible with my test code.

So, if you're trying to e2e test your API, generate test data based on your API's schema. If you're trying to component/unit test, just create "live" data instead of static fixtured data. I avoid static data like the plague.

A really cool library I've used is called pact.io. It requires tight integration from your backend teams, but it's really future proof. https://pact.io/. It claims to replace e2e testing, but it doesn't. I used it before I worked at Cypress, and they work well together. It's just like if you had a local backend that was responding.

Hi Jess, thanks for your reply. Yes, Pact seems to be really helpful for contract testing. I haven't worked with it yet but did high-level study it a bit. As I understand it, a consumer (client side) tells how the contract (the expected response data) should look like and that way establishes a contract with the provider (e.g. a back-end component / microservice). Then if a contract test fails (contract broken), the consumer and provider (e.g. 2 different teams) need to sync about the newly expected response data. This means that on the provider side (e.g. a back-end microservice) we expect to have a test working with real "live" data - so the data to test the API of that component can be prepared programatically within the back-end test itself, right?

Hi, do you know any tool for test websocket ? 🙂

Hey, all! I am having troubles running the Cypress tests in Jenkins. Has anyone successfully integrated with Jenkins and can share the knowledge or a link to a working repo + Jenkins build?

anyone aware of a ready made example how to do downloads with Cypress?

@User check out this little guy https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/testing-dom__download

Thank you! Let's see if this runs with my PR 🙂

https://docs.cypress.io/api/plugins/browser-launch-api#Set-screen-size-when-running-headless -- Just found out why I was unable to run chrome locally. I was following this piece of documentation for setting the window size of chrome when running headless. But apparently, this is already getting set by cypress so an additional --window-size that you push to the args will cause the chrome to not launch. Want me to create a an issue about this? Because 1) docs are out of date or wrong, 2) it should not fail to launch or give use feedback on why it's failing to launch a chrome proces

Hi Guys, any useful source on how to use debugger on Cypress ?

https://github.com/cypress-io/cypress/issues/17023 ANy help with this? I get unexpected character when tehre is an image being imported

@User is this e2e or component testing?

In a nutshell, png files are not text files. So they cannot be imported into js natively. But to make JS code clearer, we can use an intermediary software that will transform this file into a useful text. In webpack it's called a loader, in vite, it's a plugin. They essentially do the same thing. In component testing, we use your webpack config or vite config to select the proper loaders and plugins we use for each file import. What I expect here is one of those problems - the system is trying to import your png as text without loader (the path to the file does not match the loader) - the loader you use cannot handle the png you gave it (because of a bug or otherwise)

e2e testing.

Yeah i was trying to find the file-loader(Web pack) equivalent to browserify, no success there