Hi!
Thank you for your post! Could you tell me how can I mock POST requests?
Have you considered using the FixtureAdapter for your tests rather than mocking out the request?
If that is not acceptable, I’ve seen people recommend Sinon.js, IIRC.
Anyone tried to use https://github.com/emberjs/ember.js/tree/master/packages/ember-testing ? I didn’t found any example of usage, only small presentation: http://talks.erikbryn.com/ember-testing/#/
Yup, but had some problems with it. Erik Bryn, the author told me that Ember-testing is QUnit specific. You can check this example: https://github.com/ebryn/bloggr-client-rails/tree/master/test/javascripts
I think it is not quite stable.
Yeah, I figured it out. But do you think it is possible to:
- change some data in a test
- load ‘mocked’ GET data again
so that I can see changes in the interface?
Not quite clear what you are after. Do you have a jsbin or something that you can share to show what you are trying to do?
@morgoth yeah we worked on an example integration test using the ember-testing package you can see it here: https://github.com/Ember-SC/peepcode-ordr-test the internals for the ember testing helpers do use globals provided by QUnit stop() and start() That is a big advantage of QUnit it’s good a testing async behaviors.
I was trying to write some tests using konacha (which uses mocha) and I was getting errors like: “start is not defined”. I didn’t know that ember-testing is binded to QUnit and cannot be used with other testing libs.
Looks like QUnit requirement is no longer true after merging: https://github.com/emberjs/ember.js/pull/2626
I managed to write simple integration test using Ember RC4, https://github.com/teddyzeenny/ember-mocha-adapter and sinon for faking server requests. https://github.com/qoobaa/bridge-ember/blob/0475e1a98c49e9e8bb4f859f7b17b60a2b261a5b/test/javascripts/integration/session_test.js.coffee
@teddyzeenny thanks for this adapter.
1 Like
3 Likes
We are using jasmin , Teabag , with Rails 4 in our app unit testing of our code this is very straightforward. Also we are using Spinach ( selenium BDD wrapper ) for functional test of our rails app. Being a single page app makes the functional testing from spinach a bit flaky but its working fine till now.
We are using Rails to serve up our Ember app, mainly because we’re already used to deploying and optimising Rails apps and because we want to leverage the asset pipeline for minification and compression of the assets.
Testing is done with RSpec features, using Capybara and the Selenium driver. This works surprisingly well with a javascript-only app and because the tests are in Ruby they are quite easy to follow. Our continuous integration is done by Travis, which supports headless Selenium out of the box, so our tests also Just Work™ there.
I’m using Karma for the test runner / QUnit for the javascript test library / ember-testing for integration testing and jquery-mockjax for mock xhr support
I did a 20 minute screencast on the subject for anyone who wants to see it in action
1 Like
I’ve been wrestling with an isolated setup using Ember RC6 / Mocha / PhantomJS. After a few hard pushes I have everything working very smoothly, with one slight exception. My assertions seem to fade away, meaning every integration spec looks like it passes, even if I can see quite clearly in the error console that the assertion failed.
My primary setback was getting an initial wait time while the app set up and handling async assertions properly. I ended up taking a page from RSpec/Capybara and defined my own scenario function:
scenario = (desc, func) ->
it desc, (done) ->
setTimeout((->
Ember.run(Efflux, Efflux.reset)
Ember.run(func)
done()
), 10)
It was necessary to override the Ember.Test.Adapter as well, since it defaults to QUnit:
Efflux.Test.adapter = Ember.Test.Adapter.extend
exception: (error) ->
throw error
It is somewhere in the adapter implementation that I think I’m losing the ability to actually capture failing assertions. Anything that is wrapped in a promise gets swallowed:
# This passes, even though the assertion is incorrect
scenario 'count the number of submissions', ->
visit('/screeners/1/submissions').then ->
expect($.find('.submission').length).to.eq(2)
Can anybody lend some insight into where I’m going wrong? My assumption is that it lies in the test adapter’s asyncStart and asyncStop.
Note: I’m aware of ember-mocha-adapter, but haven’t been able to get the async behavior to play nicely with delaying the boot time.
@toranb I absolutely loved your screenscast on testing, thank you so much for doing this. Do you think you could possibly do an additional one with ember data 1.0.0? I’m currently at a complete loss about how to unit test my models 
@JulianLeviston are you looking for information or examples on how to integration test your apps (ie- when and how to mock $.ajax when you bind your template to a model or array of models?)
I’ve thought about a followup screencast but wanted to get some feedback from the community / examples about “what I want to see is …”
Would you be able to provide a few examples that I can work from? Or should I just continue the screencast as a “part 2” showing how you take the hard coded example and swap it to use $.ajax or ember-data (and show how to get the tests passing /etc) ?
Hi, thanks for the reply! … no I’m actually pretty good with how to integrate test ember apps. The “missing link” as it were, for me, was how to unit test Ember-Data 1.0.0 models given that the store is now automatigically injected wherever it’s needed within the context of the application.
As you know, unit testing models happens outside of the application execution context, and so I had no way to grab a reference to the store. Like with most stuff in Ember, it had been done for me up to that point, and I had to work out - with a fair amount of teeth gnashing - how to grab it for myself manually.
Turns out the answer was staring me in the face from a stock overflow I’d looked at several times, and it was to use App.__container__.lookup('store:main:');. That’s fine, except what was missing from the stack overflow was where to put it 
It would only work in the setup function of the qunit tests I was writing. I was trying to use it within the body of one of my tests and it was causing my tests to hang. Anyway, I’m “all good” now, with the possible exception of the fact that I’m using a private method call within the setup of my tests. It’s okay for now.
In answer to your question, though, a “part two” on Ember Data as you were going would be great. I’m not too sure on the wisdom of using Ember Data when it’s in Beta (as it’s changing a bit here and there… I recently updated my app to the latest ember data and I had to roll it back because my tests broke for some reason and I didn’t have time to work out why).
One thing I’m finding particularly irritating is testing async behaviour in my models.
For instance, at the moment I’m writing a test to check that, given a certain data context, a certain model instance’s association returns a set of data in a particular order. In pseudocode, it looks like this: 1. setup the data. 2. Get the (let’s call it “parent”) model instance from the store. 3. Call the children method on the parent object, and then 4. check that the children came out in the right order by comparing to an array.
This is really hard in Ember given my understanding of how it works.
This is the code I’m writing (tell me if it’s insane) (follows is CoffeeScript):
App.Item.FIXTURES = [{"id": 1, "name": "Parent", "parentId": null}, {"id": 2, "name": "Child 2", "parentId": 1, "order": 2}, {"id": 2, "name": "Child 1", "parentId": 1, "order": 1},]
advanceReadiness()
gatheredItemIds = $.store.find('item', 1).then (item)->
item.get('gatherChildren')
.then (gathering)->
gathering.mapBy('id')
.then (gatheredIds)->
equal(gatheredIds.toString(), '1,2', "Children gathered correctly")
wait()
So, the model is here called “item”, and it has a fairly obvious association with children. The only non-obvious thing is that the “gatherChildren” function basically gets the children in their “correct” order at the moment. Is this way of doing things insane? It’s pretty much the only way I could get it to work. Perhaps I’m not using Ember.run() enough, or something… I don’t know. Note that I’m using $.store because my setup() function had to set it to a global context. I couldn’t find a way to locally insert the variable. I guess using a helper would be a good idea, but my attempts at that were proving long and fruitless, so I just did it that way.
@JulianLeviston whoa it looks like you already have more experience testing ember-data than I do 
In your specific scenario I usually test “how” it’s used in my controller by integrating testing (using my custom Sort property on the controller itself). But if you really want the data to come back in a certain order and you need to test it at a lower level I understand that also (I just don’t do it much myself as the $ store is a black box I try to stay out of -because like you mentioned it’s been under change recently)
If you could write a blog post about this topic (as you seem to have some experience with it) please tweet it or post it here so others can learn from your awesome work