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.
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.
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.
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!