preAssignBindingsEnabled behavior is not reflected in ngMock $controller

[bathos]

Do you want to request a feature or report a bug?

Not sure how this should be classified. I suppose it’s a bug, but it concerns new stuff in RC.

What is the current behavior?

When using ngMock’s decorated $controller service in unit tests, even if preAssignBindingsEnabled is false, $controller(exp, locals, bindings) will try adding bindings old-style, prior to instantiation.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).

Demonstration with Jasmine test:

http://plnkr.co/edit/IsNy8WjASeKtp6KIpXWt?p=preview

What is the expected behavior?

When preAssignBindingsEnabled is false, I would expect ngMock to honor that.

What is the motivation / use case for changing the behavior?

If ngMock’s decoration doesn’t take into account preAssignBindingsEnabled, one could pretty easily have test results that pass which actually wouldn’t work live. This seems important because if people are converting existing code to work with the new constraints, tests will not currently reveal places where they continue to rely on attribute bindings being available in constructors.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.

6.0.0-rc0

Other information (e.g. stacktraces, related issues, suggestions how to fix)

If I change the test to use native class, it passes. I’m guessing this is because there’s a try-catch in there somewhere that falls back on binding afterwards when forced too. But outside of mocks, when preAssignBindingsEnabled is false, all controller constructors are treated as if they had been defined as ES6 classes, i.e., that they cannot be bound in advance without zany hijinks (e.g. class OneOffChild extends ActualCtrl {}, Object.assign(OneOffChild.prototype, bindings), new OneOffChild(...injections)).

[gkalpak]

BTW, it might be worth making a similar change in ngMaterial's compiler.