2

I am writing a test suite for a JavaScript widget using Intern.

I have written some pure-JavaScript tests and some in-page DOM tests, but I'm a little stuck on how to write functional tests for the Ajax functionality, which should talk to my simple Node.js mock server (which works a treat for manual tests).

Specifically, what I would like to do:

  1. Start the Node.js mock server as part of the test suite's setup phase
  2. Teardown the mock server when the test is over
  3. (Bonus points) Be able to interrogate the mock server from my Intern tests, for example, checking on the contents of a POST request to the mock

I am stuck on all three - I can't find any documentation or example code from Intern on how to handle setup or teardown of a separate process (like a Node.js mock server) in the test suite.

I am using Intern with Sauce Labs (hosted Selenium) - I'm not sure if my problem needs to be solved on just the Intern side, or on the Sauce Labs side as well. Hopefully somebody has got this working and can advise.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Alex Dean
  • 15,575
  • 13
  • 63
  • 74
  • Can you elaborate a bit on where/how you're stuck? – Shog9 Oct 02 '13 at 14:00
  • Hi Shog9 - I can't find any documentation from Intern on how to handle setup or teardown of a separate process (like a node.js mock server) in the test suite. Beyond that, I'm not sure what to say... The team behind Intern directs users to post support questions on Stack Overflow and all it's getting me is downvotes! :-) – Alex Dean Oct 02 '13 at 21:00
  • That's better. Sorry I can't help you, but hopefully someone familiar with Intern will be able to address this. – Shog9 Oct 02 '13 at 21:02
  • Thanks Shog9, I have added a little bit more background. – Alex Dean Oct 02 '13 at 21:05
  • If you don't turn up anything here, you might also try [sqa.se]. – Shog9 Oct 02 '13 at 21:08
  • Thanks - I didn't even know that one existed! – Alex Dean Oct 02 '13 at 21:09
  • 1
    Hmm, I'm not familiar with how Sauce works. Would your node mock server run on their server as well? If everything was running locally, I'd try just doing `child_process.spawn('node', ['myMockServer.js']);` in the setup phase (with some magic to avoid multiple instances). But I'm guessing using Sauce complicates that somewhat. Mocking the Ajax requests themselves is out of the question, yes? – Frode Oct 04 '13 at 15:31
  • Thanks Frode. I would rather mock the AJAX endpoint than the AJAX requests - if I mock the requests, then I'm not testing very much. When you talk about the setup phase of the tests, is there any Intern documentation on that you can point me at? I can't find any specific instructions on setup/teardown in Intern tests. – Alex Dean Oct 05 '13 at 16:13
  • The difference between mocking the AJAX request and creating a stub server is a lot of work with a minimal gain (with the stub server, you are only adding the network). OTOH, if you are testing end to end, you might want to stub your repository (so as not to mess with real user data). – zhon Oct 08 '13 at 02:08
  • 1
    @AlexDean I don't really have any good links. I've just seen from the examples at https://github.com/theintern/intern/wiki/Writing-Tests that you can have have a `setup` (called before the suite), a `teardown` (called after the suite) and a `beforeEach` (called before each test in the suite) method in the registerSuite object. – Frode Oct 08 '13 at 13:09
  • Many thanks @Frode - I had missed the `setup` and `teardown` phases. I'm going to try and rustle something up, will post an answer when I get it working. – Alex Dean Oct 08 '13 at 21:20
  • @zhon - I think there are strengths and weaknesses to both approaches. For me, "only adding the network" for a JavaScript widget is a bit like "only adding the filesystem" for a desktop app. If I am firing up 49 browser-OS combinations in Sauce Labs, it's a missed opportunity to be mocking the IO rather than testing it for real. – Alex Dean Oct 08 '13 at 21:23
  • You are right, writing a mock server could help you find problems in your widget that you might not have thought about such as timeouts, 404s, and badly formed responses. OTOH, it is easier to set up AJAX stubs to help test these scenarios. – zhon Oct 09 '13 at 14:54
  • @AlexDean Be sure to post your solution as an answer, if you find one. It would be interesting to see. – Frode Oct 12 '13 at 15:59

1 Answers1

0

If you want a server to start and stop for each suite, the setup and teardown methods would be the place to do this, something like:

var server;

registerSuite({
    name: 'myTests',

    setup: function () {
        server = startServer();
    },

    teardown: function () {
        server.close();
    },

    ...
});

startServer would be whatever function you use to start your test server. Presumably it would return an object that would be used to interact with the server. Any tests within the suite would then have access to the server object.

jason0x43
  • 3,363
  • 1
  • 16
  • 15