I recently started looking at ember-testing, and it shows a lot of promise. However, my app is very data intensive so I’m testing things like creating new records and then testing for them to be displayed. Previously, I was using Capybara request specs and had used database_cleaner in-between tests to ensure I wasn’t polluting the test database and invalidating my tests.
This afternoon, I played around with creating a database_cleaner controller in Rails. I can then clean the database in each QUnit (or Jasmine, etc) teardown (or setup) callback. This has been a big pain point for me, and I think this solution could help.
Has anyone else had problems with polluting the test database when doing ember-testing integration tests? What types of solutions if any have you seen or used? Does the one I’m proposing here sound useful?
I haven’t gotten to the point of testing yet, having just started learning Ember this week, but is there a reason you can’t use an established integration testing tool like Cucumber or RSpec and use Watir-Webdriver or a similar library to drive the browser? You could use DatabaseClearner like always in that case.
Exposting Database Cleaning as a service seems like a bad idea.
I’ve been following a suggestion that @stefan made about testing Ember applications which is to test different layers of your applications separately as much as possible. For example, if you have a Rails applications that provides the API backend for your Ember App, then you can write a very high quality and details test suite for your app in Rails using whatever method you usually use for this purpose. When testing your Ember Data adapter, you can test it without actually making calls to your API by mocking the API requests.
The only time when you would test the entire stack is when you’re creating acceptance tests. Acceptance tests by nature are the most expensive to maintain and execute(both in time to run and man hours to write). Therefore, you should only have acceptance tests for most important operations related to the business purpose of the application.
Separating your concerns in this way, simplifies your testing setup and makes sure you don’t waste your time setting up a testing infrastructure that’s overly complicated or difficult to maintain.