捕获在使用cy.intercept时未处理的请求。

huangapple go评论74阅读模式
英文:

Catch unhandled requests when using cy.intercept

问题

是否有办法让 Cypress 捕获所有未经处理和存根化的请求,而不是使用 cy.intercept。我想让 Cypress 返回一个有用的错误,以突出显示未存根化的请求的情况。目前它只允许这些请求通过,这并不有用。

如果有一种方法可以确保处理程序是链中的最后一个处理程序,那么它的架构将允许使用一个全捕获处理程序,但看起来并没有这样的方法。

英文:

Is there any way to have Cypress catch any requests that are not handled and stubbed using cy.intercept. I'd like Cypress to returns a useful error to highlight instances where a request is made that isn't stubbed. At the moment it just lets these requests through which is't helpful.

The way it is architected would allow for a catch-all handler if there was a way of guaranteeing a handler was the last one in the chain, but it doesn't look like there is any way to do that.

答案1

得分: 3

以下是翻译好的部分:

"这在技术上是可能的,这里有一个演示测试供您使用。

我基于拦截模式的前提是,拦截是按照最后定义的方式进行处理的(忽略中间件类型),所以通用拦截在所有其他拦截之前定义。

通用拦截使用 * 作为匹配器,将捕捉绝大部分请求,但只捕捉那些尚未被其他拦截捕捉的请求。

it('捕捉未被存根的请求', () => {
  
  const unstubbedRequests = []
  cy.intercept('*', (req) => unstubbedRequests.push(req))

  // 这些请求我已经存根了
  cy.intercept('https://jsonplaceholder.typicode.com/todos/1', {stub:1}).as('stub1')
  cy.intercept('https://jsonplaceholder.typicode.com/posts/1', {stub:2}).as('stub2')

  // 在应用窗口上进行一些调用,模拟真实应用程序调用
  cy.window().then(win => {
    win.fetch('https://jsonplaceholder.typicode.com/todos/1')   // 应该存根
    win.fetch('https://jsonplaceholder.typicode.com/posts/1')   // 应该存根
    win.fetch('https://jsonplaceholder.typicode.com/users/1')   // 不应该存根
    win.fetch('https://jsonplaceholder.typicode.com/photos/1')   // 不应该存根
  })

  cy.wait('@stub1')
  cy.wait('@stub2')
  cy.wrap({}).should(() => {
    expect(unstubbedRequests.length).to.eq(2)
    expect(unstubbedRequests[0].url).to.eq('https://jsonplaceholder.typicode.com/users/1')
    expect(unstubbedRequests[1].url).to.eq('https://jsonplaceholder.typicode.com/photos/1')
  })
})

注释

如果您想将此策略应用于实际应用程序,这并不是百分之百可靠的策略。

上面我使用了 expect(unstubbedRequests.length).to.eq(2),因为我知道会有两个未捕捉到的请求,并且 .should() 命令会在发送请求时出现延迟时进行重试(在此模拟中没有延迟)。

为了解决这个问题,在您的测试中,您需要提供一种在检查 unstubbedRequests 数组之前等待的方法,可以是:

但是如果等待时间不够长,这些等待方法可能会不稳定。

这是试图在测试中 证明否定 的一个后果。

理想情况下,您希望最终测试"知道"将发送的所有请求,但作为一个临时的测试开发工具,这种技术可能会很有用。"

英文:

It's technically possible, here is a demo test to play with.

I'm basing pattern on the premise that intercepts are processed on a last-defined basis (ignoring middleware types), so the catch-all is defined before all others.

The catch-all uses * as matcher which will catch absolutely everything, but only those not already caught by another intercept.

it('catching unstubbed requests', () => {
  
  const unstubbedRequests = []
  cy.intercept('*', (req) => unstubbedRequests.push(req))

  // these requests I have stubbed already
  cy.intercept('https://jsonplaceholder.typicode.com/todos/1', {stub:1}).as('stub1')
  cy.intercept('https://jsonplaceholder.typicode.com/posts/1', {stub:2}).as('stub2')

  // make some calls on the app window, simulating real app calls
  cy.window().then(win => {
    win.fetch('https://jsonplaceholder.typicode.com/todos/1')   // should stub
    win.fetch('https://jsonplaceholder.typicode.com/posts/1')   // should stub
    win.fetch('https://jsonplaceholder.typicode.com/users/1')   // should not stub
    win.fetch('https://jsonplaceholder.typicode.com/photos/1')   // should not stub
  })

  cy.wait('@stub1')
  cy.wait('@stub2')
  cy.wrap({}).should(() => {
    expect(unstubbedRequests.length).to.eq(2)
    expect(unstubbedRequests[0].url).to.eq('https://jsonplaceholder.typicode.com/users/1')
    expect(unstubbedRequests[1].url).to.eq('https://jsonplaceholder.typicode.com/photos/1')
  })
})

Notes

This strategy is not bomb-proof if you want to apply it to real-world app.

Above I've used expect(unstubbedRequests.length).to.eq(2) because I know that there will be two uncaught requests, and the .should() command will retry if there is some delay in sending the requests (there is isn't any delay in this simulation).

To get around that, in your test you would need to provide some way of waiting before checking unstubbedRequests array, either

but these waiting methods may be flaky if the wait time isn't long enough.

It's a consequence of trying to prove a negative in the test.

Ideally you want the final test to "know" all the requests that will be sent, but as an temporary test development tool this technique could be useful.

huangapple
  • 本文由 发表于 2023年6月29日 22:58:47
  • 转载请务必保留本文链接:https://go.coder-hub.com/76582264.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定