I have been working on an ember-factories library today. It should make it easy to generate ember-data models for testing etc. I’m using store.load to populate the store… The lib is still under development.
Let me know what you think and feel free to suggest improvements or help out finishing it off…
https://github.com/kristianmandrup/ember-factories
Demo app (see console of static index.html page) https://github.com/kristianmandrup/factories
I’m pretty interested in this topic as well. One thing I’ve started doing is looking around at the rest of the software community, past and present, to see what I can learn from them.
Angular in particular has put quite a bit of thought into the topic - specifically their karma test runner is a piece of art. It’s google’s orignal JSTD driver but without all the hassle. One advantage I see with this over something like konacha is that the tests run on the command line, even though they use a real browser environment – including any version of IE, mobile safari – whatever you want… It boots a server that hooks a websocket(or pulling i suppose for IE) to any browser that chooses to visit yourhost:9876 – when you press command-s, the tests run for any listening browsers. You’d only want to use just chrome by itself for quick feedback, but you could start a second server on another port, point to a different karma.config and connect using another computer on your network or with a CI server - meaning you’d have a safety net in case you break something on other browsers while developing, and therefore be able to fix it immediately… It’s not to dis-similar from buster.js - except it’s stable and extremely well maintained(by google employees - and apparently they use it to test like youtube on playstation, their ad network stuff that runs on angular, etc - so it’s not going anywhere anytime soon… )
I have not yet played with konacha, and while I definitely see it’s visual appeal(seeing your tests run is sexy), by definition of the fact that the dom manipulation is the slowest thing in the browser, it must be considerably slower than on the cli. This presentation about karma(formerly known as testacular) is worth checking out – JS.everywhere(Europe) 2012: Testacular, the Spectacular JavaScript Test Runner - Vojta Jína - YouTube — ps, if you watch this vid, it’s gonna make you want to add tests to ember documentation, the way angular has done… (that would be a nice eventual goal, one I would gladly be apart of)
Furthermore(these notes are random, sorry), setting a project up is a simple as npm -g install karma, cd your/app/dir, then run karma init – it then asks you if want to use jasmine, qunit or mocha. You can also strap your own adapter – for example, you could(in theory, want to try) use casper.js by itself, or possibly in conjunction with cucumber.js(if that’s your style) to do high level acceptance testing(outside of rails!)… It’ll also compile your coffeescript on the fly – it honestly looks like the like the shi* — its even got growl notification – let’s see what am I leaving out –
ah yes, here’s a fun fact – the name used to be testacular but changed to karma at the prodding of members from the ember crew – tom dale, ryan florence, eviltrout, etc – here’s the issue - https://github.com/karma-runner/karma/issues/376 - its funny and worth reading the comments…
Finally(long post, sorry), getting to what we can learn from the past, I am curious if anyone has any experience or comments regarding the similarities that may exist between testing ember apps and testing C#, winform, smalltalk apps, etc using the traditional MVC fat client architectures. Martin Fowler, Michael Feathers and Jeremy Miller(to name a few) have a bit to say on the subject, it’s worth reading - here are some links if your interested…
GUI Architectures (overview of the design patterns ember seems to pull from)
Vacation Rental Hacks (a rather famous example of testing said design patterns)
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/ (a crazy in depth almost book on the topic, linked to from one of the previous or someone related(dont remember))
In general, it seems we are facing the same problem as others have faced, so it would seem wise to use what they’ve learned and re-apply it here…
@emk - let me know if your interested in exchanging ideas, or anyone else on this thread for that matter - I am still way new to ember, but I find that the best way to learn something is by poking it with tests until I build up a suite that represents my understanding of the framework/language I am using… so, thanks everyone who contributes code samples here and around the web that include tests
– cheers
Konacha can also be run in the command line 
Is what I usually do! It is just more “sexy” to show how it runs in the browser 
Konacha can fx be set up to use poltergeist which uses PhantomJS headless JS driver.
My current ember-konacha-rails, will also let you set which driver you want (poltergeist, selenium or ?). The DSL is very similar to capybara acceptance tests, which is similar to cucumber but using pure code as opposed to purely textual descriptions.
But interesting with karma. Never heard of it… but hey, would be awesome to use Karma I’m sure
Also please check out Iridium, a toolchain for JS development, including testing:
Here is a nice review/overview
Hey trombom, karma looks really really interesting. Have you used it with ember.js yet? I have to admit it does look really interesting and I might actually try to set it up in may grunt toolchain.
Nope, I have not used karma with ember yet… But I am using it work my way through Test Driven Javascript Development by Christian Johansen - and I am absolutely loving it… When I start using with ember, I’ll post my finding… Hopefully sooner than later…
Thanks for the command line tip in Konacha - I think I may try that first, see what it does well and then see if I can produce similar results in Karma, compare the two and see what I find…
Also, thanks for the note on Iridium - it’s in a bookmark somewhere but would have forgotten about it – i’ll check that out as well
Slightly on-topic: Jasmine has a bug that will cause the test runner to hang until timeout when an expectation is not met and the expectation object is an ember object. Until the bug is fixed you can use a very simple workaround from this gist.
Just an update: I got sucked back into the hungry vortex of an Ember.js project. If anyone wants to take my jsFiddles and start massaging them into a tutorial on @joefiorini’s git branch, please don’t let my absence stop you. I hope to have to some free time very shortly, but you know how it goes…
FYI, I closed my PR in favor of another one by @joliss. I haven’t had a chance to work on our test suite over the past couple weeks, and may not in the near future either. https://github.com/emberjs/website/pull/452
Erik Bryn push an integrated testing package into ember today. I really like this direction. Ember integration testing solution
Hey everyone, as @kiwiupover said, we’re working on an official integration testing solution for Ember.
Here’s an example test: http://bit.ly/17spMh8
You can follow the progress in the ember-testing package: https://github.com/emberjs/ember.js/tree/master/packages/ember-testing
Hi guys!
I’m looking foward to such a guide! I’m new to TDD/BDD/testing in general, but could you recommend me a good book, the one that is beginner-friendly?
I’ve been working with a local Ember meetup group writing integration tests for the Peepcode Ordr app. We are using new helpers in the ember-testing package @ebryn mentioned. We’ve tried out mocha, jasmine, and QUnit. Then ended up putting Pavlov on top of QUnit for authoring test suites/specs in BBD syntax. See this test as an example https://github.com/Ember-SC/peepcode-ordr-test/blob/master/tests/integration/tables_test.js
So far I like Qunit w/ Pavlov the best, and the new ember-testing helpers are great.
@gcollazo has karma and mocha playing nicely with Ember.js in the brunch-with-ember-reloaded. Here’s an example test that I wrote up verifying that I had things wired up correctly:
https://gist.github.com/walter/5499168
Having said that, since @ebryn has created ember-testing for integration testing and the core team seems to strongly prefer Qunit, I’ve started work on making brunch-with-ember-reloaded use Qunit.
So far I have Qunit working under Karma in my fork (un-pushed) of brunch-with-ember-reloaded working with a simple test. I’ll keep this thread posted.
@ebryn also pointed me at Pavlov on top of Qunit. My only hesitation with Pavlov is getting into a habit with BDD style, but having that be a divergence from what Core Team does for Ember.js.
Can anyone speak to whether Core would accept Pavlov flavored Qunit tests?
Just because Ember itself doesn’t use Pavlov on top of QUnit doesn’t mean that users can’t. Obviously tests submitted to Ember itself would need to be written in QUnit.
I’ve got a work in progress branch of ember-bloggr.
ember-bloggr is the brunch-with-ember-reloaded based implementation of @tom’s screencast of a simple blog.
I may throw Pavlov into the mix after I get things with vanilla Qunit working properly.
Will post back as things progress.
P.S. - Discourse breaks emacs keybindings that work across Mac OS X when editing markdown in text areas… my fingers no likey
For details on where I’m stuck, see this comment on the 2nd commit.
Any help appreciated.
I began a fork of Konacha using Qunit and Pavlov instead of Mocha/chai.
See: https://github.com/Ember-SC/konacha/wiki
There are links on that wiki page to an example app (Peepcode Ordr app) with integration tests and uses the (Qunit) fork of konacha too. Currently, the konacha fork is a work in progress but it does execute the test runner in iframes using your choice of browser and via Selenium (Capybara).
Konacha seems like a very good choice for tooling when developing an app with Rails, but is dialed into Mocha/Chai. It seemed good to me to try out another option QUnit/Pavlov.
Is there anything like the Angular Scenario runner for Ember?