cypress-io/cypress

Stubbed XHR that are triggered between 2 tests are not stubbed

eprevot opened this issue · 2 comments

eprevot commented

Current behavior:

  • In test 1, I stub some routes
  • In test 1, I cy.visit() my application that triggers some XHR (some stubbed and some not stubbed), I check what I need and I don't wait for all XHR to end
  • In test 2, I cy.visit() my application, the page is reloaded but it randomly happens that some requests triggered by the previous test "bleed" in this test

My problem : the XHR that are stubbed in test 1, are not stubbed when bleeding in test 2

Expected behavior:

Either XHR requests should not bleed in next test or at least they should remain stubbed

Additional Info (images, notes, stack traces, etc)

When requests are bleeding in another test, it looks like this (test block appears before before each block) :
capture d ecran 2017-06-15 a 18 37 33

Bleeding requests usually are not a problem, since I cy.visit() at the beginning of each test, they don't interfere with the test. But some XHR should not reach my server on CI environment, that's why I stub them. When they reach the server on CI, they cause an error 500, and we configured our CI to make the build fail when there is any error on server. That's why I need them to stay stubbed.

From what I understood of our discussion on gitter with @brian-mann :

  • it could be a race condition where the XHR is created post teardown, after cypress unrolls all the stubs, but before the page is unloaded (before next cy.visit)
  • cypress should remove the application entirely before running the end of test teardown (that would prevent any javascript from running, execution would end), then unroll things and prepare for the next test
  • enforcing teardown won't work for users that don't cy.visit between each test
  • cypress should not teardown the app IF its the last test, so you can visually inspect it post test
  • Operating System: Mac OS 10.11
  • Cypress Version: 0.19.2
  • Browser/Browser Version: Chrome 59
brian-mann commented

This is documented in detail here: #686

jennifer-shehane commented

Unfortunately we have to close this issue due to inactivity. Please comment if there is new information to provide concerning the original issue and we can reopen.