If you want to directly jump to jsFiddle code, it is here: http://jsfiddle.net/bbkxK/2/
Ideally, I would expect both instances of the object to produce "something else" for the message.
Here's the context: We have a massive Ember application, and we want to use a configuration binding approach, specifying the appropriate default bindings for global singleton in our class definitions (if you want to go tangent and say it's terrible, and there is a better one way, I’m all ears. I don’t like our current architecture, but it follows the patterns developed by Ember devs through sample applications).
So, we specify default bindings that “just work” in the running application. And everything's good. The problem is when we start unit testing. As soon as we scored about 500 unit tests, we had problems with test isolation. In some tests, the state of a singleton controller will be updated, and then other tests will fail. In the past few weeks, he has turned into a huge mess and time.
To isolate the tests, we started trying to override the default bindings specified at the class level in the test object instances that we created in our unit tests. Often we try to replace the binding to singleton with a static reference to the layout of the object. Still with me?
After trying many different approaches, the best strategy I came across is a template MyApp.classWithDeferredDefaultBindings, which you can see in the jsFiddle example ( http://jsfiddle.net/bbkxK/2/ ).
But ... this is much more verbose than the normal Horrible way to do something, and it just doesn't seem right. I think we could create a mixin or monkey-patch Ember to make it better, but there seemed to be a good time to get in touch with the developers and the community before we take this step.
So, my multi-volume question: is our approach to overriding single-user default bindings appropriate in the context of unit test? Should we make a request to use Ember to support this more smoothly? Can you say that this is actually a mistake within the framework?