562234 - Add a mock XHR object to the Jetpack SDK

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Atul Varma [:atul]]

A whole lot of Jetpack code, and possibly a number of low-level Jetpack APIs such as l10n (see bug 549315) need to use XHRs to access various web-based services.

As far as unit testing goes, the easiest way to QA this kind of code is to use mock objects, as it will be both extremely fast (resulting in a short code-test cycle for developers) and flexible (meaning it's easy to simulate unusual situations that are difficult to reproduce in practice).

Since an XHR actually has a somewhat nontrivial interface, it'd be really helpful to ship a mock class for it with the SDK, so that anyone writing code that uses XHRs can mock them out easily.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

This is something it would be great to have sooner than later.

Comment 2

[Atul Varma [:atul]]

Upgrading status to P1 blocker so this shows up as super important in my bugzilla dashboard (http://bit.ly/bzdash).

Comment 3

[Atul Varma [:atul]]

I've got a basic version of this up at my personal repo. Here's the tiny test suite so far:

  http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/file/19c89cb9463b/packages/mock-xhr/tests/test-mock-xhr.js

Does this kind of thing seem usable? A number of methods aren't implemented yet, but the basic ones are.

One funny thing is that the 'xhr' module doesn't implement add/removeEventListener() but does implement onreadystatechange, while this mock does the opposite--need to fix that.

Comment 4

[Atul Varma [:atul]]

Attachment: link to mock xhr test suite

Myk, could you provide feedback on this?  does it look like it'd be useful for mock testing RESTful web services?

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 444695 [details]
link to mock xhr test suite

If I understand this correctly, the way it would work is that a module being tested that calls require("xhr") would (unbeknownst to the module) get this mock XHR module instead of the normal XHR module.

Then, when the module being tested creates requests, the mock XHR module returns fake data as the results of those requests instead of actually accessing the network.

If so, that seems like a perfectly reasonable and quite useful tool for testing modules that do network stuff via XHR, so feedback+!

The only thing the current implementation seems to be missing is a way to register fake data to return when a module makes a call.  It should be possible for a test file to do something like:

  require("mocks/xhr").register(url, fakeDataToReturn);

Comment 6

[Matěj Cepl]

I got a great results with Java class described in http://www.javaworld.com/javaworld/jw-07-2002/jw-0719-networkunittest.html?page=3 (code is attached to the article as well). It provides various other options, like getting an input stream which breaks connection after n bytes are read, etc.

Comment 7

[Atul Varma [:atul]]

I've added a really simple mechanism for allowing for Myk's suggestion in Comment 5, but it only lets you register a "global delegate" that's assigned to any XHR's a require('xhr').XMLHttpRequest()-using module creates. Not a big fan of the way it works right now, but here's a code example:

  http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/file/21a7aa67e750/packages/mock-xhr/tests/test-mock-xhr.js#l77

Comment 8

[Atul Varma [:atul]]

I think I'm probably going to build on my simple mechanism by adding helper methods that make it really easy to do common things, e.g. myk's example code in comment 5.

I'm thinking that the common 'use cases' for these are returning a '200 OK' with given text content and returning error status codes? Are there any others?

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #8)
> I'm thinking that the common 'use cases' for these are returning a '200 OK'
> with given text content and returning error status codes? Are there any others?

Returning XML that is parsed into a DOM (like responseXML does), setting arbitrary headers, responding to GET/POST appropriately. Ideally, all the tests I wrote in bug 547091 attachment 447657 [details] [diff] [review] (and maybe more) should be doable with mock XHR.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 11

[Myk Melez [:myk] [@mykmelez]]

It doesn't seem like we've actually needed this.  If things change, let's file a new bug and work on it there.

Comment 12

[Atul Varma [:atul]]

Hmm, so one bummer about not having this (or just talking to a local web server, as deitrich had originally recommended) is that there are a bunch of tests in test-request.js that are commented out:

  https://github.com/mozilla/addon-sdk/blob/master/packages/addon-kit/tests/test-request.js

Those were waiting for this bug to be fixed before they were commented out. So much work would be involved in writing mocks, though--i didn't realize how extensively the request module uses the XMLHttpRequest interface--that it might just make sense to bust a real localhost webserver for the request module tests.

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

Myk: how are we going to test any XHR interactions without this?

Comment 14

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #13)
> Myk: how are we going to test any XHR interactions without this?

We're going to bust a real localhost webserver (bug 561926).

Comment 15

[Matěj Cepl]

(In reply to Myk Melez [:myk] from comment #14)
> (In reply to comment #13)
> > Myk: how are we going to test any XHR interactions without this?
> 
> We're going to bust a real localhost webserver (bug 561926).

Could I do with a real localhost webserver (even if that bug will be ever fixed, which doesn't seem likely given the silence over there) things like broken connections, getting just first 200 bytes and then breaking connection etc. These things could be done with Java class mentioned in comment 6.

Comment 16

[Myk Melez [:myk] [@mykmelez]]

(In reply to Matej Cepl from comment #15)
> Could I do with a real localhost webserver (even if that bug will be ever
> fixed, which doesn't seem likely given the silence over there) things like
> broken connections, getting just first 200 bytes and then breaking
> connection etc.

Yes, it's possible to emulate all these behaviors with a localhost webserver.