Testing route models when dependent on modelFor

What is the best way to go about testing the data/models in routes? More specifically, when a child route depends on a parent route?

I have a parent route like /admin/accounts/:id, and then a bunch of sub/child routes like /admin/accounts/:id/preferences, /admin/accounts/:id/something, /admin/accounts/:id/users, etc.

The parent route returns a model from the store like so.

model() {
    return this.get('store').findRecord('account', params.account_id)

And then in the child routes I do something along the lines of this to get the parent route’s model and re-use it.

model() {
    return this.modelFor('admin.acccounts.details');

That’s all great, but a couple days ago I updated the data in my parent route and all my child routes/templates broke because the model definition changed. Whoops! The parent route was updated to return…


So now all the child routes would have to be updated to reflect that change. Totally my fault for failing to think about this, but this feels like the sort of thing a unit test on the routes would’ve been wonderful at detecting. The thing is, I have no idea how I’d do that in an Ember unit test.

Can someone point me in the right direction? How would you wire up the route unit tests to reflect this? OR is this a bad smell, and I should be moving away from modelFor and just re-fetch the data from the store in each route? OR would most people say to lean on the acceptance tests, and route unit tests for model data are kinda meaningless?

I don’t think there’s anything wrong with using parent models in child routes, in fact i think it’s a common pattern and is the preferred approach to many situations so I’d say keep using modelFor. I think the best way to test this would just be acceptance testing the child routes. Since unit tests are supposed to be isolated they wouldn’t really help you diagnose situations like you ran into above.

Great point @dknutsen. Since the route’s model is entirely dependent on another route, it probably doesn’t make sense as a unit test. acceptance tests are probably much more ideal in this case.