AngularJS component event binding test passes even with no component event binding

[rmorrise]

Do you want to request a feature or report a bug?
Test framework bug or possibly a documentation issue?

What is the current behavior?
I am looking at a component unit test that is formulated just like the one in the AngularJS docs for component:
it('should call the onDelete binding when a hero is deleted', ...)

Even if I comment out the binding in the component definition ("onDelete"), the test will still pass.

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

1. In the configuration of the component under test, comment out the event binding:
   //onDelete: '&',
2. Execute the test "component: heroDetail should call the onDelete binding when a hero is deleted"

The test will still pass.

What is the expected behavior?

It seems to me like the best behavior would be to not bind the unspecified property when $componentController is invoked, which would result in a test failure.

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

The test should verify that my component config is correct, and fail otherwise.

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.

Tested in AngularJS v1.5.2 (latest versions of Karma+PhantonJS).

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

Here is the doc page in question:
https://github.com/angular/angular.js/blob/master/docs/content/guide/component.ngdoc

[gkalpak]

This is expected behavior, since we are testing the controller is isolation (i.e. we don't care if it is used in a directive and what bindings it might have). $componentController will just assign the bindings we pass to it on the controller. This lets us test directive/component controllers, without having to setup and interact with an actual element and the DOM (including compiling and linking), which speeds things up.

That said, the test is not so useful, because we are testing nothing inside the controller (i.e. there is no logic inside the controller related to calling onDelete).

I think it makes more sense to change the template from ng-click="$ctrl.onDelete({hero: $ctrl.hero})" to ng-click="$ctrl.deleteHero()" and then introduce a new method in the controller: this.deleteHero = function() { this.onDelete({hero: this.hero}); }.
Then, we can modify the test to call deleteHero() and verify that onDelete was called with the appropriate arguments.

@rmorrise, would you like to submit a PR for that ?

[rmorrise]

@gkalpak: Thanks for your reply.

I already have written a separate unit test for the controller class using $controller. Shouldn't the component test focus on the component options class, not on the controller implementation?

What I want to test is the component options class, which specifies the controller by name and also specifies the bindings. For example, if my component specifies a binding like:

selectedProjectViewItem: '<forFolder'

...I would like to be able to set the 'forFolder' property in the input map and verify that it's mapped to the correct controller property. Isn't this a more useful test of the component?

[gkalpak]

I already have written a separate unit test for the controller class using $controller

Not sure what you mean by that. Do you mean in your app ?

Basically, the test that we are talking about - the one using $componentController - can only test the controller. Basically, $componentController is the exact equivalent of $controller with the exception that it can retrieve the controller constructor right off the DDO. What this means, is that you no more need to specifiy the controller separately (using .controller(...)) in order to be able to test it in isolation.

Without $componentController:

.directive('myDir', function () {
  return {..., controller: 'MyCtrl'};
})
.controller('MyCtrl', ...)

With $componentController:

.component('MyComp', {..., controller: function () {}})
// Actually it works with `.directive()` as well, as long as it has `controller`, `controllerAs` and `restrict: 'E'`

Now, you can still test the controller is isolation, even if you haven't registered it separately.

I would like to be able to set the 'forFolder' property in the input map and verify that it's mapped to the correct controller property.

For that, you need to compile a piece of HTML with the component.

Isn't this a more useful test of the component?

Both tests are useful.

For you real-world app, you should test both aspects. Often you can test everything from the second kind of test (including a whole component), but tests involving DOM and compiling are a tiny bit slower than pure JS tests. So, if you have lots of components, it is preferrable to test their controller with pure JS tests (no DOM involved) and only test the rest of the aspects (e.g. bindings being passed correctly, callbacks being bound to the correct elements etc) in DOM-involving tests.

For the developer guide, we don't need (nor have) thorough test coverage, so it's OK if we only show one kind of tests. IIRC, the goal of this particular example was to showcase the recently added $componentController.

tl;dr
I still believe the change I proposed above is a desirable one 😃
If you feel like adding an extra test involving a whole component, feel free to (as long as you can keep it reasonably simple).