allow the use of api-stub for test:ci and test commands

[taras]

Currently, api-stub is only enabled on server and server:test commands.

It should work uniformly across all test tasks.

[rwjblue]

Looks like Karma supports proxies which should work, but we'll need to tweak the configuration to start the server before calling test:ci (I think):

  proxies =  {
    '/static': 'http://gstatic.com',
    '/web': 'http://localhost:9000'
  };

Config file documentation: http://karma-runner.github.io/0.8/config/configuration-file.html

[taras]

I started working on this. I encountered a hick up with configuration of Karma proxies. I'll create a PR with what I have later today or tomorrow morning.

[FilmKnurd]

I ended up modifying the grunt config to make the api-stub work across the board. I can submit a PR.

[taras]

@rjackson @stefanpenner the last commit - #f37c977 in my PR adds expressServer:debug task to test, test:ci and test:browsers.

This commit also remove also removes the ability to specify proxy method via command line.

IMO, that functionality should be either implemented differently or removed because it makes Gruntfile.js unreadable.

It nullifies #367.

[FilmKnurd]

@taras Agreed. My PR just added the existing command line helper into the other tasks. I like your refactoring.

[FilmKnurd]

@taras It looks like the reason @pangratz did not enable the stub for tests is because tests should fake the server: #336 (comment)

[taras]

@FilmKnurd thanks for the link, I thought that might have been the case but when using with stubs it creates a different scenario. I think its a matter of consistency and its either one away or another - ie. either we do stubs that we serve or fake server with mock content.

@stefanpenner might have something to say about this. He mentioned some reservations that he has about faking the server during in a hangout that happened a few weeks ago.

[FilmKnurd]

I've been using the stub for running the server during development and when deploying for demos. For tests, I've been using mockjax.

[FilmKnurd]

I suppose the nice thing about the current setup is that it gives you the option to opt-in to using the stub for tests. I think that was the intent behind @pangratz PR.

@taras Why does it have to be either / or?

[taras]

@FilmKnurd it doesn't have to be either/or but if we are going to enable both options then both should be complete.

This commit completes the stubs implementation.

Currently, EAK doesn't have anything to enable fake server setup. If we say that when testing you should use fake server then we should at least provide what's necessary to do that. ( i think )

[taras]

But I gotta say, I do like the idea of faking requests. I was using Trek's fakehr and ember-httpRespond library and that was very nice because it was very fast. The problem was that I had to manually load my static content.

I wouldn't mind doing a good integrating of fakehr & ember-httpRespond libraries into EAK.

[FilmKnurd]

@taras How would you compare the fakehr & ember-httpRespond to mockjax?

[FilmKnurd]

I think providing a solution for faking/mocking server requests is an excellent idea.

[FilmKnurd]

Oh and @taras thanks for polishing up the stub.

[taras]

@FilmKnurd there is a good discussion about HTTP mock in Discourse http://discuss.emberjs.com/t/http-mocking-for-ember-testing/2846/15

I think one of the biggest advantages is that its built by Trek with focus on Ember.

Its a good idea, so its my pleasure.

[FilmKnurd]

Would we need to embed those libraries, since they don't have packages?

[taras]

We would create a separate package with all of those libraries combined and then include the package into EAK.

[rwjblue]

Just submitted PR's to:

https://github.com/trek/ember-testing-httpRespond/pull/3
pretenderjs/FakeXMLHttpRequest#2
trek/fakehr#2

Once this is done it will be trivial to add these to our bower config.

[taras]

@rjackson or like that. Should we create a separate issue for this?

[rwjblue]

@taras - Created: #369

[FilmKnurd]

Now addressed in #375

[pangratz]

@taras It looks like the reason @pangratz did not enable the stub for tests is because tests should fake the server: #336 (comment)

Sorry to join the party so late. IMHO the network should not be hit when testing the application, that's why I didn't add this to the initial implementation. I haven't followed the project to close lately but I think this is now possible, right?

[FilmKnurd]

@pangratz The way things will work after #375 is merged, is that all routes that are not mocked by httpRespond, will fall through to the api stub.

Tests do not have to talk to the api-stub, but they do out of the box. I think this accommodates both scenarios: 1. wanting to use the api-stub as the source of test data and 2. Not wanting to use the api-stub, but instead mock all the test data.

[FilmKnurd]

But in either case, both the test code and the app code use the RESTAdapter, which I think is the big win here.

[pangratz]

Tests do not have to talk to the api-stub, but they do out of the box. I think this accommodates both scenarios: 1. wanting to use the api-stub as the source of test data and 2. Not wanting to use the api-stub, but instead mock all the test data.

Sounds good!

[rstudner]

Has this been pushed through or not yet? I seem to be unable to use apistub for mocking out my tests (for the sole reason of just have RESTAdapter everywhere vs switching adapters)

[cdeszaq]

👍 This would make our lives so much easier!