【问题标题】:Nightwatch Mock HTTP RequestsNightwatch 模拟 HTTP 请求
【发布时间】:2026-01-27 20:25:01
【问题描述】:

我尝试使用 nock 和 sinonjs 等其他库模拟 HTTP 请求,但没有成功。

import nock from "nock"

const URL = "http://localhost:8080/"

const SIGN_IN_PATH = "/fake/users/sign_in.json"

export const signInRequest = (status, payload = {}) => {
  return nock(URL).get(SIGN_IN_PATH).reply(status, payload)
}

-

import { signInRequest } from "./../../utils/fakeRequests"

const doLogin = (browser) => {
  return browser
          .url("http://localhost:8080")
          .waitForElementVisible('form', 1000)
          .setValue('input[name=email]', 'foo@foo.com')
          .setValue('input[name=password]', 'somepass')
          .click('button[type=submit]')
          .pause(500)
}

export default {
  "Do login and shows error message": (browser) => {
    signInRequest(403)

    doLogin(browser)
      .waitForElementVisible('.error', 1000)
      .end()
  }
}

nightwatch 是否可以模拟 http 请求?

【问题讨论】:

  • 同样的问题,有解决办法吗?
  • 不幸的是,不是。 :( 。要解决此问题,您可以启动模拟服务器并更改 url 值以在测试环境时使用模拟服务器地址。
  • 也许,这可以帮助你:*.com/questions/38353886/…

标签: mocking nightwatch.js nock


【解决方案1】:

Nightwatch.js 是一个端到端的测试工具 - 所以关键是实际的 UI 以及它们调用的 api 将是实时的(而不是模拟的) 因此,也许您正在寻找一个专为集成测试设计的框架,例如 casper.js (http://casperjs.org/) 或 nightmare (https://github.com/segmentio/nightmare)

但是,我相信 nightwatch 中的模拟 http 调用应该可以使用 nock 来实现(如果您有一些奇怪的用例需要这样做) 确保您在测试之前确定 http 调用(它们甚至可以在 before 块中),例如:

module.exports = {
  'test abc' : function (browser) {
    nock('http://example.com')
      .get('/users')
      .query({name: 'martin'})
      .reply(200, {results: [{id: '123'}]});

    // do test stuff
  },
};

您的示例可能存在的问题是您模拟整个 UI - nightwatch 可能会以某种方式阻止同一个域被拦截。将 UI 和 API 放在不同的域(或端口)上可能会解决问题

【讨论】:

  • 有些人懒得解释 :) +1
  • 如何在不依赖后端的情况下单独运行 UI 测试是一个奇怪的用例?您可以为这两种情况编写测试 - 当 API 按预期运行时,以及当它们不按预期运行时 - 并通过不必依赖实际服务来节省运行测试的时间。
  • 我是说守夜人并不是真正的工具。它并不是真正用于集成测试。也许 cypress 更适合该用例,因为它是一个更通用的浏览器测试框架(或者我在原始帖子中提到的旧版本之一,如果它们仍然是最新的)
  • @Marty 你说想要在没有真正后端服务的情况下测试 UI 的用例是“奇怪的”。这与说 nightwatch 不是该案例的正确工具不同——这可能是投反对票的原因......有充分的理由测试一个 HTML/CSS/JS 前端,其行为类似于真正的浏览器,但没有使用真正的后端服务,以及对于 JS 重/单页应用程序前端世界(如我)相对较新的人来说,为什么不应该使用与 e2e 测试相同的工具来完成这一点并不明显。不过,感谢您的提示! ;)
  • 顺便说一句,这里有一个关于如何完成的很好的提示:*.com/questions/46183354/… - 但这并不能解决我们可能还想检查 SPA 是否正确地向后端服务发出请求的问题,即使这些在之后不会对应用程序本身产生任何影响......因此模拟服务需要更智能,并且还需要记录请求并将这些记录提供给测试进行评估 - 类似于npmjs.com/package/wdio-intercept-service。但理想情况下,两者都有一个工具。