I'm reading the source code and found my understanding of this API is wrong.

Completely works well.

describe('componentOutputs', () => {
  it('invokes given callback when an output is emitted', async () => {
    @Component({ template: `` })
    class TestFixtureComponent {
      @Output() event = new EventEmitter<void>();
      emitEvent() {
        this.event.emit();
      }
    }

    const mockEmitter = new EventEmitter<void>();
    const spy = jest.spyOn(mockEmitter, 'emit');
    const { fixture } = await render(TestFixtureComponent, {
      componentOutputs: { event: mockEmitter },
    });

    fixture.componentInstance.emitEvent();

    expect(spy).toHaveBeenCalled();
  });
});

But, I have no idea why this is needed. What is the difference between componentProperties?

After diving deeply, I found the answer.

• componentInputs calls componentRef.setInput, so it can trigger OnChanges and OnPush safely.
• componentOutputs just set the new value to the field. no other side-effects.
• componentProperties looks ... a deprecated pattern. It is complex to trigger change detection after assigning.

I feel the current documentation is not enough to tell the proper API usage to the users. At least, I'd like to improve the documentation of componentOutputs.

Hey @lacolaco you're 100% right.
componentProperties was what we had before, but we can now have fine-grained control with componentInputs. To still be able to set outputs, we've added componentOutputs.

Do you think these changes are worth it to deprecate componentProperties in favor of the new properties? My opinion is that the new properties are favored, but on the other hand componentProperties makes it easy to just set properties and render the component.
It also allows to set public properties of the component that are not inputs or outputs.
I didn't have a case for this yet, but I assume it could happen in some codebases.

@timdeschryver Thanks for clarifying. I can totally agree with you. I think it is not easy to drop componentProperties because as you say it could happen in edge cases to mutate class non-input/output fields.

We'll see how it goes and we can re-evaluate later.
Perhaps a ESLint rule would be ideal in this case 🤔
Feel free to clarify this behavior in the docs if you want.

@timdeschryver I've submitted a PR! #372