How Should Your Ember Tests Look?
Tests are obligatory in every production app. In Ember apps, the distinction between tests is similar to any other Rails application, but the use cases for them are frequently misunderstood.
Let me give a quick summary of what your test suite should look like based on my experience with a huge app, which spent over a year under constant development.
Tests are obligatory in every production app. They give you confidence in what you’re currently developing, but more importantly, they make sure that maintenance and further features won’t break the business logic. In Ember apps, the distinction between tests is similar to any other Rails application - acceptance, unit and integration tests. But the use cases for them are frequently misunderstood. Let me give a quick summary of what your test suite should look like based on my experience with a huge app, which spent over a year under constant development.
Acceptance tests
The first mistake that a lot of beginners make is to base their confidence on acceptance testing. Why? The reason is simple - most of us find them the easiest at the beginning. You use selectors as a reference, perform user actions and the asynchronous helpers do all the work regarding the Ember Run Loop. But I strongly recommend that you don’t stick with acceptance as the most important type of test. First of all, they are extremely slow compared to unit and integration tests. They require the application to reload after each test. Moreover, they only test the page you are visiting, not the components that are used on the page and may be used in other pages (it’s not good to repeat yourself!). Even though acceptance tests look like a quick win, having them as a large part of your test suite is effectively a tech-debt that you’ll have to pay back in the future.
You may find that the tech-debt collector comes knocking at your door in the form of a slow test suite. If so, don’t remove your tests (which would also be a huge mistake - they’re fine but slow). Try to refactor them to use some page objects (see this excellent talk by Lin Reid) and minimise the test cases by merging them in user paths. Instead of the test placing messages in your inbox - leaving, archiving and searching separately - simply perform these tasks in order in a single test case. You’ve just earned a couple of seconds that were taken up by reloading the app each time.
Unit tests
Unit tests are a little bit harder for beginners to understand, but must eventually find a place in your toolbelt. They are extremely fast, and they’re perfect for testing routes and controllers. However, the first hurdle for beginners is how to use ember-data and other services that you inject in your controllers or routes. Actually, I strongly recommend that you mock everything that you can. Test the logic paths that your methods should perform with nearly the same data as the real ones. For instance, you don’t need to use ember data in unit tests to create records. You can mock store to return the Ember.Object with same attributes as your model:
Integration tests
This is still not widely used by developers, as it’s quite a recent test option. However, I find it extremely interesting and useful for testing your components. You can easily render components in the test scope, test user behaviour and do everything that the component does nearly as quickly as using the unit tests. Also, if you mock everything as in unit tests, it can be very easy to work with them. Don’t be afraid of the Ember Run Loop, as integration tests hide it from you and save you from any problems with it! Integration tests can be checked out in this excellent blogpost by Alisdair McDiarmid. Unfortunately, they are not properly documented in the Ember Guides - they present acceptance tests as integration tests. It’s misleading, so I suggest you stick to the above blog post.
End-to-end testing
While working with Ember.JS, I found that testing your API and Ember app separately simply doesn’t give enough confidence and may end up with breaking the app when you subsequently make changes in the code. If you mock your API in acceptance tests, you can never be sure if the mocks will accurately mirror the behaviour of the real API. Therefore, a green light on both applications does not mean that the feature you tested on both of them will ultimately work. This has landed me in some extremely stressful spots, so I recommend that you make sure to avoid such situations. End-to-end testing is something relatively new to me, so I cannot say if our process is flawless - we still need a few weeks of testing. I intend to write a blog post about our setup in a couple of weeks, but for now, you can check out this post by Dockyard about their approach.
Summary
In summary, I would like to stress again that testing is an essential part of Ember applications. You should try to divide your test suite to make it both as fast as possible and provide enough confidence to work with the code. Take advantage of mocking during unit and integration tests and don’t rely fully on acceptance testing. If your app is a commercial project, don’t forget about end-to-end testing - make software that is reliable.
