How do we make Trek's Pretender play nice with Ember Testing?

Testing
1

All,

I raised a stackoverflow question last week and have had exactly zero responses to it, so I’m looking to this site in the hope I may be able to get some direction.

In the interest of not duplicating things, you can read the detail here: How do we make Trek’s Pretender play nice with Ember Testing?

In short, I’m really keen to use Trek’s Pretender in my Ember testing but it isn’t promise and run loop aware and I’m looking for some inspiration on how we might rectify this (something akin to how httpRespond works).

Does anyone have any suggestions/advice/opinions in how I might look in to doing this?

Thanks in advance for any light you may be able to shed on this.

PS: I will endeavour to create some code based examples to illustrate my question if it is not entirely clear

1 Like
2

I was just talking about this same thing with @locks or someone else on irc last week.

My thought was to create a sort of plugin that is model aware, and you can define endpoints based on model name. This would only work when working with ember-data. Would love to hear your take on this.

I’ve yet to start anything, but have created a repo to get started: https://github.com/knownasilya/ember-pretender

3

Hi @knownasilya,

I was actually thinking more along the lines of using Pretender much like httpRespond is being used, only, I guess the mock responses are setup in one place at the start of the test as opposed to where ever they are actually needed.

The thing that I think limits httpRespond, for me, is that it doesn’t have the concept of inspecting the request and returning a response based on that, which is what I am after.

And thinking further ahead still, my greater aim is to use Pretender as a part of an Ember-fied version of github.com/realestate-com-au/pact

Would you mind explaining a little more about what you had in mind?

4

We use it this way:


var pretender;
module('Acceptances - Posts', {
  setup: function() {
    pretender = new Pretender();
    pretender.get(window.ENV.namespace+'/posts', function(request) {
      var content = JSON.stringify(postsFixtures);
      return [200, { "Content-Type": "application/json" }, content];
    });
  },
  teardown: function() {
    Ember.run(App, 'destroy');
    if (pretender) {
      pretender.shutdown();
    }
    pretender = null;
  }
});
1 Like
5

Yep, that’s how you use it. But that’s not really what I mean. I’ll put together a code example to illustrate what in trying to do.

6

Here’s the AAA (arrange, act, assert) syntax I’m currently working on supporting using Pretender:

  expectAjaxGet({
    path: '/api/posts',
    queryParams: {
      text: 'something to search for'
    }
  });

  andThen(function() {
    store.find('posts', { text: 'something to search for' });
  });

  verifyAjax();

The idea is that you can call expect as many times as you want and optionally provide a response object (404 is the default). You can also call stub to set a response without failing if the call is not made.

verifyAjax will assert that all of your expectations were met by the code under test.

This is how the Rhino .Net testing library behaves and it makes for very clear tests - here’s what I expect to happen - did it happen?

I’ve got one bug left to fix and then I’ll have the test helpers ready to publish.

Thoughts?