@andrewmp1 wrote:
A few of us from the OC Ember meetup group are working on experimenting writing integration tests around the Peepcode Ordr app in a repo here:
https://github.com/OC-Emberjs/peepcode-ordr-test
As Peter said a lot of the current testing components are being influenced by whatever backend/build system you are using.
I'm inclined to take a test runner like Testem or Karma and work towards using that for tests as its not tied to any backend. There is a split between what style of tests you like to write between qunit, jasmine, and mocha. For integration tests it seems like it really comes down to how they handle async tests. For unit tests I think the most popular has been jasmine. I think qunit has the best async support, but mocha's async tests are the easiest to grock. Also W/ integration tests you end up fighting between your app wanting to take over the html page and your test runner creating html elements to report results as most apps I've seen are attached to the body element. Konacha is great as it uses an iframe to get around this, but too tied to its(rails) backend in my opinion. We have tests being run on the peepcode ordr app using two different runners ("JS Karma, Testem"). It looks like Karma already runs tests in an iframe while testem doesn't. I'm working on pulling out the iframe runner stuff from Konacha to use it in Karma or Testem w/ a custom setup. In all of this I'd love to see more ways to be able to write integration tests that don't use timeouts and maybe some kind of DSL to have a simple way to select and trigger input elements on a page.
Just thought I'd do a brain dump on the topic real quick.