# HTTP Mocking for ember-testing

**URL:** <https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846>\
**Category:** Proposals\
**Created:** [October 2, 2013, 2:10pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846 "2013-10-02T14:10:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 2, 2013, 2:10pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/1 "2013-10-02T14:10:59Z")

</div>

Typically, I write integration tests in the same manner I write Ember.js apps: totally separated from any HTTP services that the service(s) it might communicate with (e.g. not from within `ember-rails` or another server framework integration library).

This creates a somewhat interesting problem when writing integration tests: how to provide mocked data to the application in way that mirror connection to an actual service. I imagine for people who use `ember-rails`, they drive integration tests with rspec and fill their database with the correct data before running each test.

For those not integrating with a service, I’d like to see HTTP mocking added to ember-testing to better control what happens when specific responses are returned.

There are three main ways I’ve seen people mock data that comes from the server: fixtures, fake servers, and response emitters.

You’ll be familiar with fixtures if you use a library like `ember-data` or `ember-model`: you supply an adapter that has some canned data available so when you make a request for, say `find('post', 1)` it never goes to the server and just loads your fixture data.

I love fixtures for prototyping but I think they’re not ideal for integration testing for the simple reason that using them will leave your custom adapter code totally unexercised: it’s easy to have a bug with url, HTTP verb, or success handler that goes unnoticed in testing.

Faker servers are probably the most common type of HTTP mocking around. If you’ve used [sinon](http://sinonjs.org/) in the browser or something like [webmock](https://github.com/bblimke/webmock) on the server you’re familiar with this style. You set up the requests you’d like intercepted and the responses they should load ahead of time and then run you tests.

In Ember, it might look something like this:

```javascript
var server = new FakeServer({
  "/rest/ember/show": {
 
  },
 
  "/rest/product": {
    products: [
      {id: 1, name: "foo"}
    ]
  },
 
  "/rest/ember/create": {
    fields: [
      {id: 1, name: "summary"}
    ],
 
    product: {
      id: 1,
      name: "foo",
      components: [
        {id: 1, name: "foo component"}
      ]
    }
  }
});

```

I think this approach works well in synchronous environments, where the pattern emerged, but don’t offer the fine-grained control you’d want in asynchronous environments. For example, if you wanted to check of the presence of loading views or test what happens when the response order of two simultaneous requests varies.

Response emitters is the pattern I’ve been using myself. It involves emitting a response at a specific point in the flow of execution by chaining a promise or integrating with the [promise-free helpers, should we ever add them](http://discuss.emberjs.com/t/ember-testing-improvements/1652)

```javascript
visit("/invoices")
.httpRespond("get", "/api/v1/invoices", {... response object ....})
.click(".remove-invoice")
.httpRespond("delete", "/api/v1/invoices/13917998", {"message":"Invoice was successfully deleted!"})
.then(function(){
  equal(find("#flash-message").text(), "Invoice was successfully deleted");
})

```

Because the `{... response object ....}` can get pretty big, we’re also using a factory library, but this is roughly how it works.

So, I need some feedback:

1. Should we add HTTP mocking into ember-testing
2. Would you prefer a strategy of fixtures, fake servers, response emitting, or something else?
3. What extra features would you find handy (e.g. failing a test if there are requests that weren’t responded to or a requests is triggered that isn’t intercepted)?

---

<div class="post-metadata">

**Author:** ![eviltrout](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/eviltrout/32/14169_2.png) [@eviltrout](https://discuss.emberjs.com/u/eviltrout)\
**Post date:** [October 2, 2013, 2:20pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/2 "2013-10-02T14:20:44Z")

</div>

Discourse uses mocking with fixtures right now and I’ve found it quite effective. We don’t use ember-data, so all of our Ajax goes through one `Discourse.Ajax` endpoint.

In testing mode, `Discourse.Ajax` will look for a fixture named the same thing as the URL being contacted. If it exists, it returns a promise with the contents from that file. If a path is contacted without being represented by a fixture, it logs an error to the console so it can be caught.

We also have a rake task that populates the fixtures, given a running instance of a dev server.

As for the fake servers / response emitting, I can’t speak to that. But I can say the fixtures have suited us well and caught a lot of bugs.

---

<div class="post-metadata">

**Author:** ![twokul](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/twokul/32/13811_2.png) [@twokul](https://discuss.emberjs.com/u/twokul)\
**Post date:** [October 2, 2013, 2:28pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/3 "2013-10-02T14:28:24Z")

</div>

One thing that would be handy is “timed out” or “failed” requests. That should cover testing scenarios for slow or mobile networks.

---

<div class="post-metadata">

**Author:** ![Domenic](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/domenic/32/15144_2.png) [@Domenic](https://discuss.emberjs.com/u/Domenic)\
**Post date:** [October 2, 2013, 2:31pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/4 "2013-10-02T14:31:29Z")

</div>

(I do not use Ember day-to-day so take anything I say with a grain of salt.)

1. HTTP mocking is a great feature for any client side tests. I think it would be ideal if this were reusable and agnostic to Ember, i.e. if you set out to make the best HTTP mocking library in the world, which didn’t need to run within ember-testing or QUnit. But I understand that’s probably adding unnecessary constraints that don’t help your users.

2. The response-emitter version looks very nice, and as you say, is the most flexible. If I had to choose one, it would be that. Beyond that, fake servers are a simplicity and separation-of-concerns win for the 80% case, so if there’s bandwidth to implement those as well, that would be great.

3. It’s important to make the failure cases almost as easy to test as the success cases, as error handling flow is often under-tested. Thus APIs should be able to send back arbitrary status codes, not just 200, or they should be able to timeout, or perhaps even simulate an XMLHttpRequest abort.

---

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 2, 2013, 2:39pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/5 "2013-10-02T14:39:05Z")

</div>

> [@Domenic](#):
>
> I think it would be ideal if this were reusable and agnostic to Ember, i.e. if you set out to make the best HTTP mocking library in the world

The libraries are already totally framework agnostic and consists of two parts: One provides a `FakeXMLHttpRequest` constructor that mirrors the `XMLHttpRequest` spec but adds methods for forcing a response and a one add swaps native xhr for fake xhr and does the recording process.

Some of this code is cribbed from sinon and a few other sources that packaged these things too tightly. The goal wasfor either library to be useful on its own.

---

<div class="post-metadata">

**Author:** ![toranb](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/toranb/32/16579_2.png) [@toranb](https://discuss.emberjs.com/u/toranb)\
**Post date:** [October 2, 2013, 2:53pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/6 "2013-10-02T14:53:29Z")

</div>

For what it’s worth, I’m using jquery.mockjax with great success for both jQuery $.ajax projects (like discourse) and ember-data projects as it’s just xhr mocking at the core

[https://github.com/appendto/jquery-mockjax](https://github.com/appendto/jquery-mockjax)

Here is a simple example of what my helper looks like (used with ember-testing)

```
function stubEndpointForHttpRequest(url, json) {
    $.mockjax({
        url: url,
        dataType: 'json',
        responseText: json
    });
}

$.mockjaxSettings.logging = false;
$.mockjaxSettings.responseTime = 0;

```

Then from my tests I simply setup a given xhr like so

```
test('ajax response with no embedded records yields empty table', function() {
    stubEndpointForHttpRequest('/api/others/', []);
    visit("/others").then(function() {
        var rows = find("table tr").length;
        equal(rows, 0, "table had " + rows + " rows");
    });
});

```

I’m using this for a full suite of integration tests around my django adapter and it’s rock solid so far. For anyone looking to see an example check out the branch for ember1.0

[https://github.com/toranb/ember-data-django-rest-adapter/blob/ember1.0/tests/adapter\_embedded\_tests.js](https://github.com/toranb/ember-data-django-rest-adapter/blob/ember1.0/tests/adapter_embedded_tests.js)

---

<div class="post-metadata">

**Author:** ![rsmossuk](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@rsmossuk](https://discuss.emberjs.com/u/rsmossuk)\
**Post date:** [October 2, 2013, 6:11pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/7 "2013-10-02T18:11:37Z")

</div>

I use Sinon’s Fakeserver throughout my Ember integration test suite which works really well so if you can do this instead using Ember it would be great.

I have not looked at the response emitters pattern. Does this actually fake the http request the same as fakeserver does but just enables you to request and respond in a more controlled way / time ?

---

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 2, 2013, 6:55pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/8 "2013-10-02T18:55:02Z")

</div>

> [@rsmossuk](#):
>
> I use Sinon’s Fakeserver throughout my Ember integration test suite which works really well so if you can do this instead using Ember it would be great.

Sinon comes with a lot of stuff that Ember folks won’t need. The approaches are similar to each other, but event emitting allows for exact control of where in the application flow a response is triggered.

---

<div class="post-metadata">

**Author:** ![rsmossuk](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@rsmossuk](https://discuss.emberjs.com/u/rsmossuk)\
**Post date:** [October 2, 2013, 7:49pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/9 "2013-10-02T19:49:56Z")

</div>

great +1 for that then cheers

---

<div class="post-metadata">

**Author:** ![mixonic](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/mixonic/32/14829_2.png) [@mixonic](https://discuss.emberjs.com/u/mixonic)\
**Post date:** [October 3, 2013, 1:21pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/10 "2013-10-03T13:21:46Z")

</div>

I think this is a tricky nut to crack, and I hope more people chime in with their ideas. Some thoughts:

Regardless of how XHR is stubbed or supplanted (with fixtures for example), **having a robust factory language would be a huge boost**. I have yet to use an API-dump for tests in practice, so I’m often stuck writing JSON responses by hand. When you have a lot of relations, this quickly becomes hard to manage. That said there are so many possible JSON variations right now (JSON-API, ActiveModelAdapter, RESTAdapter) that I’m not clear on how we could build one DSL. Perhaps the Ember-Data serializer API itself could be used for converting fixtures into response JSON?

Needing to type out all the URLs for an HTTP response also feels messy- The adapter knows how to generate the URL for a given request. **Can we use `adapter.buildURL` to generate API routes?**

My biggest issue with [Sinon](http://sinonjs.org/) is how it fails. **In `autorespond` mode, if you request a URL the fake server has no `respondWith` declaration for the server will just hang.** This is way more frustrating than debugging an unexpected 404 or timeout. Usually a GET parameter has changed and you didn’t notice, then half the tests start hanging. Very frustrating to debug, since one hanging test obscures all other failures.

The proposal here looks more like Sinon’s `respond` flow. I’m a bit confused as to how it would work- Today the `visit` step is unfulfilled while XHR is processing (since the XHR is often in a promise for the `model` hook). How would specifying the http response after `visit` has resolved work? Does this imply that `visit` will no longer fulfill after the route has been entered, but at some earlier point? Does this have impact on other integration test flow?

One advantage of the `FixtureAdapter` is that you can actually save and update data on it. I would love to see that functionality baked into an XHR mock.

Maybe I’m really hoping for something halfway between fixtures and XHR stubbing. It would have factories generating data based on a DSL involving the model, be able to provide API urls, and do basic persistence (or maybe manually stub out a specific response’s behavior).

---

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 3, 2013, 3:38pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/11 "2013-10-03T15:38:26Z")

</div>

> [@mixonic](#):
>
> having a robust factory language would be a huge boost.

Totally agree, but that’s a separate concern we’ll need to solve.

> [@mixonic](#):
>
> Can we use adapter.buildURL to generate API routes?

👎 if there is an error in your `buildURL` that you rely on in your tests, your tests will pass even though there is an error. Plus not ever app uses `ember-data`, so we can’t rely on its presence.

> [@mixonic](#):
>
> FixtureAdapter is that you can actually save and update data on it. I would love to see that functionality baked into an XHR mock.

That already exists, since it’s just a response:

```javascript
  .click('.save-button')
  .httpRespond('post', '/images', { ... })

```

---

<div class="post-metadata">

**Author:** ![gstroup](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/gstroup/32/4881_2.png) [@gstroup](https://discuss.emberjs.com/u/gstroup)\
**Post date:** [October 3, 2013, 4:11pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/12 "2013-10-03T16:11:44Z")

</div>

Sorry for the self-promotion, but I created a little mock server for this sort of integration testing: [apimocker - npm](https://npmjs.org/package/apimocker). It will return XML or JSON from a static file. You can also change responses at runtime, and set latency to test your asynchronous handling. Hope you find it helpful.

---

<div class="post-metadata">

**Author:** ![jkintscher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jkintscher/32/15150_2.png) [@jkintscher](https://discuss.emberjs.com/u/jkintscher)\
**Post date:** [October 4, 2013, 3:43pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/13 "2013-10-04T15:43:46Z")

</div>

Much like @toranb I’ve had great success so far using jQuery.mockjax as a way of XHR mocking for my integration tests at a really low level.

Using a slightly more complex test helper allows to not only set the status code of the response but also load it from an external JSON file:

```
// called with `mock_http('posts', 'posts/index');` to mock `GET /posts`
// or `mock_http('posts/1', 'posts/deleted', 204);` to mock `DELETE /posts/1`

function mock_http(url, fixture, status) {
    Ember.$.mockjax({
      url: url,
      dataType: 'json',
      proxy: FIXTURES_DIR + '/' + fixture + '.json',
      status: status || 200
    });
}

```

This way you can not only mock standard GET requests but also test successful PUTs, DELETEs, and, most importantly, error handling of all sorts. Having the ability to define those mocks on a per-test basis has been working well and using external files even allows for re-use on the server which will give you even more confidence in the tests.

I definitely agree that having a way of mocking HTTP requests built right into ember-testing is necessary to make integration testing more seamless and something that’s missing right now.

---

<div class="post-metadata">

**Author:** ![benmoss](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/benmoss/32/15152_2.png) [@benmoss](https://discuss.emberjs.com/u/benmoss)\
**Post date:** [October 4, 2013, 6:33pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/14 "2013-10-04T18:33:10Z")

</div>

I think the response emitters pattern looks nice. Right now I’m using Sinon and do find that setting up the endpoints outside the context of the interactions makes them feel a bit disconnected. It also seems like it would be a lot clearer if you’re expecting the same endpoint to return different responses over time, whereas trying to emulate that server state with Sinon can be a bit clumsy.

Having the option to turn on automatic failures for un-mocked requests would be really handy, as @mixonic mentioned those can be the source of some pretty annoying test bugs.

---

<div class="post-metadata">

**Author:** ![ryanto](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ryanto/32/13850_2.png) [@ryanto](https://discuss.emberjs.com/u/ryanto)\
**Post date:** [October 4, 2013, 8:30pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/15 "2013-10-04T20:30:15Z")

</div>

When testing my Ember applications I generally use the fixture adapter. I think the fixture adapter is great for read based applications (lots of querying, little saving) since it is great at materializing models/relationships from data.

The biggest problem I have with the fixture adapter is that saving large graphs becomes difficult. If I want to save an model and I expect my API to sideload a whole bunch of changed data in the response this is really difficult with the fixture adapter. Currently, I’m extending the fixture adapter on a per model adapter basis and having create/updateRecord emulate these large changes while saving the record in test mode. This is hard to maintain though.

I think the HTTP mocking inline with the tests is a really cool solution. It’s great because if your API is really shitty (and lets be honest, most API responses suck) it allows you to test your adapter and serializer rules as part of your integration tests.

Something I am worried about is that the HTTP mocking ties our tests too close to the adapter. Switching from RESTAdapter to AMSAdapter means I could have to change a number of tests.

I’m using a factory in test mode to quickly build objects, but I really like the suggestion of having a factory that builds json/http responses. I think that alleviates my concern above, not having any actual “json” in your suite.

---

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 5, 2013, 9:53pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/16 "2013-10-05T21:53:01Z")

</div>

OK friends, I’ve put something up for people to play around with. There are basically three parts:

- [https://github.com/trek/ember-testing-httpRespond](https://github.com/trek/ember-testing-httpRespond) the helper with example use. It has two dependencies (that follow).

- [https://github.com/trek/fakehr](https://github.com/trek/fakehr) a library for XHR intercepting. It is not specific to Ember.js or any test framework. It has one dependency (listed below).

- [https://github.com/trek/FakeXMLHttpRequest](https://github.com/trek/FakeXMLHttpRequest) a object that behaves like the native XMLHttpRequest. It is not specific to Ember.js, a test framework, or a HTTP recording library.

Play around and let me know how it works.

---

<div class="post-metadata">

**Author:** ![benmoss](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/benmoss/32/15152_2.png) [@benmoss](https://discuss.emberjs.com/u/benmoss)\
**Post date:** [October 9, 2013, 3:56pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/17 "2013-10-09T15:56:23Z")

</div>

> [@trek](#):
>
> we’re also using a factory library

which library are you using?

---

<div class="post-metadata">

**Author:** ![trek](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/trek/32/14207_2.png) [@trek](https://discuss.emberjs.com/u/trek)\
**Post date:** [October 9, 2013, 4:23pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/18 "2013-10-09T16:23:03Z")

</div>

Just something we put together ourselves

---

<div class="post-metadata">

**Author:** ![pixelhandler](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/pixelhandler/32/18649_2.png) [@pixelhandler](https://discuss.emberjs.com/u/pixelhandler)\
**Post date:** [October 14, 2013, 6:04am UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/19 "2013-10-14T06:04:07Z")

</div>

@trek thanks for putting together the mocking tools, I was looking into a bug and created a couple jsfiddles to compare, one using Sinon and second using your fakehr/FakeXMLHttpRequest:

Using Sinon: [Ember Data Canary - JSFiddle - Code Playground](http://jsfiddle.net/pixelhandler/ePQ5x/)

Using fakehr: [Ember Data Canary - JSFiddle - Code Playground](http://jsfiddle.net/pixelhandler/7ZWZg/1/)

I liked the `fakehr.requests` method it was easy to inspect what ember data was sending via ajax.

Would you think the fakehr fiddle example would be something helpful to add to the contributing guide here: [https://github.com/emberjs/data/blob/master/CONTRIBUTING.md#reporting-a-bug](https://github.com/emberjs/data/blob/master/CONTRIBUTING.md#reporting-a-bug) ?

---

<div class="post-metadata">

**Author:** ![rwjblue](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/rwjblue/32/9411_2.png) [@rwjblue](https://discuss.emberjs.com/u/rwjblue)\
**Post date:** [October 14, 2013, 1:13pm UTC](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/20 "2013-10-14T13:13:50Z")

</div>

> [@benmoss](#):
>
> which library are you using?

You may want to checkout: [teddyzeeny/ember-data-factory](https://github.com/teddyzeenny/ember-data-factory). I’ve just started using it, and it has been fitting my needs perfectly.

[Next page](https://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846.md?page=2)