Ember Data Test Improvements

Ember Data
1

I just got off the phone with @stefan.penner and @ghempton about some improvements that we’d like to make to Ember Data.

Many of the frustrations that people experience with Ember Data now are due to bugs and not deficiencies in the architecture. As such, we’d like to make some improvements to how Ember Data gets tested. Our plan is to slowly refactor towards these goals, with an eye towards pragmatism.

More Modular Tests

Many of the tests in Ember Data were written as the architecture of the project was evolving. The organization of these tests leaves something to be desired, and it is often difficult to track down a specific test as it may be in one of several monolithic test files.

We would like to start to break these up into smaller, more targeted tests. Integration tests should focus on testing specific features; unit tests should test a single object.

Testing Helpers

Many test files define their own inline testing DSL for DRYing up tests. Where possible, we should identify common helpers, extract them, and use them everywhere. That being said, we should not make this too magic. Understanding tests should not require getting intimately familiar with a heavily abstracted testing framework.

Test Suite for Adapter Authors

One piece of feedback we’ve received from adapter authors is that they’re not sure how much of the adapter API they need to implement to get certain features. We’d like to provide a test suite (à la Promises/A+) that allows adapter authors to ensure that their adapter works with all of the features in Ember Data, including parent/child relationships, embedded records, and committing multiple records at once. This should help increase the quality of adapters, and also allow users of those adapters to better understand which features they support.

We welcome the communities support and thoughts on our above proposals. If there is anything specific you’d like to see, let’s discuss it here! We’re super excited about the future of Ember Data!

6 Likes
2

This is awesome. I’m currently working on an adapter and sometimes I’m not quite sure how to properly test without a backend API running or resorting to mockjax or similar.

Thanks!

3

This sounds fantastic! This has been one of my biggest gripes with ember-data and ember.js. A conscious effort to keep the test suite clean and logical will go a long way to making it easier to understand the ember internals and contribute back to the project.

If you don’t mind I’d like to make a few suggestions:

1. The location of test files should follow a convention. Here is an example of the current layout for the rest adapter

packages/ember-data/lib/adapters/rest_adapter.js

packages/ember-data/tests/unit/rest_adapter_test.js

Instead it should be

packages/ember-data/lib/adapters/rest_adapter.js

packages/ember-data/tests/unit/adapters/rest_adapter_test.js

2. Run the build against a real app that uses the most common ember-data features. This will give you a higher degree of confidence that the build actually works in real life. It would be really useful if you need to do a large scale refactoring that touches many parts of the framework, as it gives you a good safety net if you deleted any unit tests.

4

We should consider integrating a code coverage tool into our testing workflow:

https://github.com/gotwarlost/istanbul

2 Likes