Allow Dynamic Stubbing and Responses

Current behavior:

Currently, all mocked responses need to know the response data upfront.

cy
  .server()
  .route("/users", [{id: 1, name: "Kyle"}])

The stubbed route can also include dynamic routes, but the response will always be static upon the route being initialized.

cy
  .server()
  .route(/api\.server\.com, SingleFixture)

Expected behavior:

1. The ability to setup fixture responses dynamically. Perhaps using some sort of controller function.

cy
  .server()
  .route(/api\.server\.com/, FixtureController)

function FixtureController(request, response) {
  if (request.url.contains('users') {
    response.body = [{id: 1, name: "Pat"}]
    return request
  }

  if (request.url.contains('login') {
    response.body = { token: '123abc' }
    return request
}

1. The ability to match all routes, but conditionally allow some responses to be stubbed, and others to request real data. In the above, perhaps if response wasn’t set, the request would continue to the server.

Test code:

function FixtureController(request, response) {
	if (request.url === 'api.server.com/users') {
		response.body = { hello: "world" }
		return response
	}
}
describe(`Dynamic Stubbing`, () => {

	beforeEach(() => {
		cy.server().route(/api\.server\.com/, FixtureController)
	})

	it('should stub a route dynamically', () => {
		cy.request('http://api.server.com/users').then(function(response) {
			expect(response.body).to.have.property("hello", "world")
		})
	})
})

• Operating System: OSX
• Cypress Version: 0.19.2
• Browser/Browser Version: Chrome Latest

[alexlee-dev]

So we are almost 2 years after this problem was initially brought up. I see people have written some pseudo fixes for different problems, but none of them seem like a catch all (at least for XHR).

Does anyone from Cypress have an update on this? @brian-mann ?

Love Cypress, and I’d like to be able to use it more dynamically.

[brian-mann]

@ianwalter we are not likely going to change or update any of the existing route / wait API’s because ultimately the whole thing needs to be rewritten and implemented in a completely different fashion.

Here’s an issue describing it: https://github.com/cypress-io/cypress/issues/687

When we rewrite those API’s we will take this use case into account.