Should I be able to override bindings specified at the class level in an instance?

Question

If you want to jump directly the the jsFiddle code, it's here: http://jsfiddle.net/bbkxK/2/

Ideally, I would expect both object instances to output "something else" for theMessage.

Here's the context: We have a massive Ember app, and we want to use a convention-over-configuration approach by specifying appropriate default bindings to global singletons in our class definitions (if you want to go off on a tangent and argue that's horrible and there's a better way, I'm all ears. I don't love our current architecture but it follows the patterns set forth by Ember devs via the example apps).

So we specify default bindings that "just work" in the running application. And all is well so far. The problem is when we start unit testing. Once we hit about 500 unit tests, we started having problems with test isolation. Some test would update the state of a singleton controller and then other tests would start to fail. It has turned into a huge mess and time sink the last few weeks.

To isolate the tests, we started attempting to override the default bindings specified at the class level, in the test subject instances we were creating in our unit tests. Often, we would try to replace the binding to singleton with a static reference to a mock object. With me so far?

After trying many, many different approaches, the best strategy I've come up with so far is the MyApp.classWithDeferredDefaultBindings pattern you can see in the jsFiddle example (http://jsfiddle.net/bbkxK/2/).

But... it's so much more verbose than the normal Ember way of doing things, and it just doesn't feel right. I guess we could create a mixin or monkey-patch Ember to make it better, but it seemed like a good time to reach out to the devs & community before we take that step.

So my multi-thronged question is: Is our approach reasonable for overriding default singleton bindings in the context of a unit test? Should we be making a feature request to Ember to support this more seamlessly? Can you argue it's actually a bug in the framework?

Answer 1

First off, I just want to preface that we really need to write more about how to test with Ember.

I think it's a good rule to say that binding to absolute paths inside of class definitions (relying on singletons) is a big no-no. It's fine to use relative binding paths though.

I would advise you to steer clear of using singletons. It makes it much harder to test. The common practice is that you should always define your controllers as classes. Then you can instantiate them in your app and your tests. Much easier and less error prone than trying to deal with singleton usage in your tests.