6

I try mocking HTTP requests with nock and other libs like sinonjs but without success.

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()
  }
}

Its possible mock http requests with nightwatch?

Bruno Quaresma
  • 9,457
  • 7
  • 32
  • 50

1 Answers1

9

Nightwatch.js is an end to end testing tool - so the point is that actual UIs as well as the api they call will be live (and not mocked) So maybe you are looking for a framework designed for integration tests like casper.js (http://casperjs.org/) or nightmare (https://github.com/segmentio/nightmare)

However mocking http calls in nightwatch should be doable with nock i believe (if you have some strange use case that warrants it) Ensure that you're nock http calls are before tests (they can even be in a before block), eg:

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

    // do test stuff
  },
};

Possible problem with your example is that your mocking the entire UI - nightwatch might be somehow preventing the same domain from being intercepted. Having your UI and API on different domains (or ports) might solve the issue

Marty
  • 2,965
  • 4
  • 30
  • 45
  • 1
    some people do not bother explaining anything :) +1 – artin Apr 21 '18 at 12:30
  • 3
    How is wanting to run your UI tests in isolation without reliance on the backend a strange use case? You can write tests for both scenarios - when the APIs behave as expected and when they do not - and save time running your tests by not having to rely on actual services. – zero_cool Jul 26 '19 at 21:04
  • I’m saying nightwatch isn’t really the tool for that. It’s not really for integration tests. Maybe cypress is more appropriate for that use case as it’s a more general purpose browser testing framework (or one of the older ones I mentioned in original post if they are still current) – Marty Jul 28 '19 at 12:43
  • 1
    @Marty you say the use cases of wanting to test a UI without the real backend services is "strange". That is not the same as saying nightwatch is not the right tool for that case - that might be the reason for the downvote... there are good reasons to test a HTML/CSS/JS Frontend with something behaving like a real browser but without using real backend services, and to people relatively new to the JS heavy / single page app frontend world(like me) it's not obvious why this shouldn't be done with the same tools as e2e tests. Thanks for the nock hint, though! ;) – Henning Oct 06 '19 at 23:19
  • BTW a good hint on how it could be done is here: https://stackoverflow.com/questions/46183354/mock-backend-in-nightwatch-js-tests - but that doesn't solve the problem that we might also want to check if the SPA is doing requests to backend services properly, even if these don't result in any effect in the App itself afterwards... therefore the mock service would need to be smarter, and also record requests and give these records to the test for evaluation - something like https://www.npmjs.com/package/wdio-intercept-service. But ideally one would have a single tool for both. – Henning Oct 06 '19 at 23:23