Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stubbing requests via cy.intercept doesnt work the same way as cy.route #15050

Closed
Tevinthuku opened this issue Feb 11, 2021 · 8 comments · Fixed by #16415
Closed

Stubbing requests via cy.intercept doesnt work the same way as cy.route #15050

Tevinthuku opened this issue Feb 11, 2021 · 8 comments · Fixed by #16415
Assignees
Labels
topic: cy.intercept() type: unexpected behavior User expected result, but got another

Comments

@Tevinthuku
Copy link

Tevinthuku commented Feb 11, 2021

Current behavior

The request I want to stub looks like so with the old cy.route

cy.route({
			method: 'POST',
			url: '**/sessions',
			status: 200,
			response: {
				success: true,
			},
			headers: {
				'x-token': "token",
			},
		})

With this, I get the "x-token" returned as a header back to the client. alongside other headers.

connection: "keep-alive"
content-length: "16"
content-type: "application/json; charset=utf-8"
date: "Thu, 11 Feb 2021 12:58:34 GMT"
vary: "Accept-Encoding",
x-token: "token"

Trying out the new cy.intercept API,

cy.intercept('**/sessions', {
			body: { success: true },
			headers: {
				x-token: "token"
			},
		})

This is what I get back

content-type: "application/json"

Desired behavior

I expect the x-token to be part of the headers returned in the response.
If Im missing anything, please let me know, thanks

Test code to reproduce

https://github.com/Tevinthuku/cypress-test-tiny
https://codesandbox.io/s/modest-hofstadter-gl5xj?file=/src/App.js

Versions

Cypress v 6.4.0

@Tevinthuku
Copy link
Author

Tevinthuku commented Feb 11, 2021

Based on this reproduction
https://github.com/Tevinthuku/cypress-test-tiny
https://codesandbox.io/s/modest-hofstadter-gl5xj?file=/src/App.js

with cy.route() the x-token header gets passed down , and the test in cy-route.js passes as it should,
but with cy.intercept() the test passes, but the function, at the response level it doesnt get the x-token header.

@lc-leoniefarmer
Copy link

I am experiencing the same issue. This code should add a header to every request, but I don't see any header added to my requests:

beforeEach(() => {
  
  cy.intercept('*',(req) => {
    req.headers['my-test'] = 'TEST'
  })
})

@sainthkh
Copy link
Contributor

sainthkh commented May 3, 2021

It's a CORS problem. The problematic code's domain is https://csb-gl5xj-g6j2kdska.vercel.app/ and it requests to domain, https://dummyendpoint.com. When CORS requests, x-token header cannot be accessed. Check this answer.

We can currently bypass this problem by adding Access-Control-Expose-Headers like below:

it('works', () => {
  cy.visit('https://csb-gl5xj-g6j2kdska.vercel.app/')
  cy.intercept('**/sessions', {
    body: { success: true },
    headers: {
      'Access-Control-Expose-Headers': 'x-token', // <= ADD THIS LINE
      'x-token': 'token',
    },
  }).as('loginRequest')

  cy.get('[data-testid=username-input]').type('user')
  cy.get('[data-testid=password-input]').type('userpassword')
  cy.get('[data-testid=signin-button]').click()
  cy.wait('@loginRequest').then((res) => {
    let headers = res.response.headers

    expect(headers).to.have.property('x-token')
  })
})

@flotwig I think there can be several solutions for this problem:

  1. Automatically append 'Access-Control-Expose-Headers': '*' to all requests. It can sometimes cause false positive.
  2. Don't append it and document about the CORS issue. It's a bit tedious to add 'Access-Control-Expose-Headers' to every test.
  3. Provide exposeHeaders config. Different endpoints might have different exposed headers.

What do you think is the best solution? Maybe there can be other better ones.

@sainthkh sainthkh added topic: cy.intercept() stage: awaiting response Potential fix was proposed; awaiting response labels May 3, 2021
@jennifer-shehane
Copy link
Member

@sainthkh We already automatically pass some CORS headers. See this PR: #9384

@jennifer-shehane jennifer-shehane added the type: unexpected behavior User expected result, but got another label May 3, 2021
@sainthkh
Copy link
Contributor

sainthkh commented May 4, 2021

@jennifer-shehane I checked the PR and the change is related with the CORS origin, not the exposed header properties. The PR doesn't do anything with Access-Control-Expose-Headers property. It only handles access-control-allow-origin and access-control-allow-credentials.

@flotwig
Copy link
Contributor

flotwig commented May 4, 2021

@sainthkh of the 3 options you've listed, I think it would make sense to modify (1) slightly and go with it:

Automatically append 'Access-Control-Expose-Headers': '*' to all stubbed requests. It can sometimes cause false positive.

If we only apply it to stubbed requests, like we do with the other CORS headers, it should help avoid unnecessary modification of the header.

Another issue was opened about this same confusion, so it's probably worth fixing: #14654

@sainthkh sainthkh self-assigned this May 5, 2021
@jennifer-shehane jennifer-shehane added stage: ready for work The issue is reproducible and in scope and removed stage: awaiting response Potential fix was proposed; awaiting response labels May 5, 2021
@cypress-bot cypress-bot bot added stage: work in progress stage: needs review The PR code is done & tested, needs review and removed stage: ready for work The issue is reproducible and in scope stage: work in progress labels May 10, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented May 10, 2021

The code for this is done in cypress-io/cypress#16415, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot cypress-bot bot removed the stage: needs review The PR code is done & tested, needs review label May 10, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented May 10, 2021

Released in 7.3.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v7.3.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators May 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic: cy.intercept() type: unexpected behavior User expected result, but got another
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants