https://cypress.io logo
When contributing to Cypress, how can I test a dev...
# i-need-help
h
I'm taking a look at writing a PR to fix a bug I filed in Cypress a little while back (https://github.com/cypress-io/cypress/issues/24407), and I wanted to test my fix by using my local development version of Cypress instead of a published version to see if it fixes my reproduction example project. I followed the contributing document and made a build of Cypress with my fix using
yarn build
. Then, in my bug reproduction project, I switched the Cypress version in
package.json
from a normal published version to point into the local pre-release build (
"cypress": "file:../cypress/cli/build"
). When I run an npm install in the reproduction repo, I get a message saying
Warning: You are installing a pre-release build of Cypress.
, which is fair, but then the install fails with
Error: Failed downloading the Cypress binary.
. The URL it's saying it tried is https://cdn.cypress.io/beta/binary/12.6.0/darwin-x64/develop-49fdb6bbf1aba86728c219e6b4c04a41299a23d1/cypress.zip, which seems to legitimately be a 404, probably because the hash is of something that isn't a published binary. Does anyone know if it's possible to get this binary installation step to succeed in local development?
w
It should be possible to do what you've described, I don't have the answer off the top of my head, maybe somebody else can provide it. It sounds like generally the right approach. There might be an easier way where you can sidestep all of it, I want to make sure you are familiar with it. If you have a branch of Cypress, running
yarn dev
at the root of the Cypress repo will append the
--global
flag which opens Cypress in global mode. This lets you choose to open any Cypress project on your machine from the running version of Cypress, without having to modify the project at all. Then you could run your tests with your bugfix applied and see how it goes. Unless you think the behavior would be different in the binary, or something, which seems unlikely for the issue you linked.
h
That's a good idea, I wasn't familiar with Cypress's global mode. I'll give that a shot!
That worked, thanks @wonderful-match-15836 ! Now to see if I can find a reasonable place to add test coverage - the piece of middleware affected doesn't seem to have any test coverage currently.
Looks like packages/proxy/test/unit/http/request-middleware.spec.ts has the closest analogues
w
hmm feel free to put up a draft as well, somebody on the e2e team can give feedback on best testing setup. If you've found a place with no tests, it's great to set up some but it might be more work than you bargained for.
h
That's roughly my read of the situation, it's a one line fix so I may put it up and ask for guidance on testing if it doesn't prove straightforward.
There at least seems to be some harness code for testing these middlware, but this particular one is not covered
I'll give it a crack
w
when you make the PR feel free to tag me, I'm looking at contributor PRs this week and will assign reviewers
h
I took a crack at the unit test coverage but this particular unit may be more than I bargained for
The req/res objects seem to need to be quite complete to test this middleware, more complete than any of the existing middleware unit tests
4 Views