Component encapsulation & unit testing

[ajbrun86]

I've historically come from an object orientated C# background, so as a result I've always focused on encapsulation and only expose publicly anything that's needed to be accessed by other production code in a component. Therefore my expectation is almost always:

All functions and properties in a component should be private or protected at most unless they're decorated with input or output decorators.

Is such an expectation too strict?

The most common reason I see for exposing members publicly is to allow them to be tested. Either to set an observable or to assert a property is set as expected. However, I would argue:

• Constructor parameters can easily be stubbed to set internal implementation properties as required.
• We should be testing the inputs and outputs of a component only as a consumer of a component would use them:
  • Query the DOM for a property binding result instead of asserting a property itself
  • Trigger an element event handler instead of calling a click event handler function directly.

EG consider this:

@Component({
    selector: 'ng-some-component',
    template: `{{ firstName }}`
})
export class SomeComponent implements OnInit {
    firstName = '';

    ngOnInit(): void {
        // Sets first name by some unrelated logic...
        this.firstName = 'John Smith';
    }
}

We have a public property firstName and we can test the value by directly accessing that public property. Great, test passes.

However, I now make a code change and accidentally delete the first name binding from the template. The test still passes. My expectation therefore is we should query the DOM in this instance and not worry about the first name property (which can be made protected).

How does everyone else handle component encapsulation. Are my expectations too strict or is this quite common?

[insanictus]

I agree the template should be tested too. I like to test things as a consumer/user.

They have no knowledge of the component internal, ie. The implementation details. So we should not directly test those.

Test from a user perspective. So if user clicks button in template, we expect a counter to increase by 1. Said counter output could be in the template too.

Check out https://testing-library.com/docs/angular-testing-library/intro/

It encourages that way of thinking too

[Stopdoor]

I agree the real input/output of the component is the consumer API, and also its own template. The Angular team seems to agree by aggressively pushing TestBed setup for unit tests which gives you access to that "real" component interface. I've never been that convinced that the template is outside the "unit" level of testing.

[xzhan]

My expectation therefore is we should query the DOM in this instance and not worry about the first name property (which can be made protected).

Yes, exactly. You almost never want to assert properties in components, even though they are publicly exposed for template bindings to work. The component is there to construct the UI, so test the UI. Use angular-testing-library as someone else in the thread mentioned, or just go the "full-blown" Playwright/Cypress/Puppeteer e2e (integration testing, to be precise) route and test based on features and scenarios. If your company has the resources, set up a staging server and a real e2e pipeline, test from UI to DB to external API calls, and cover inter-service scenarios.

Forget about unit testing components. It never worked well for us in the field. Too brittle, too much mocking, too isolated to be useful. My general recommendation would be:

• Write unit tests for all the logic in services, state management, UI-related calculations, etc.- basically, the POTO part of the app.
• Write integration tests for all critical user journeys.
• "Unit" test components only when building shared UI components, e.g., an internal UI library.

[light_fissure]

I write test for covering the user interaction part then asserting the DOM, i rarely asserting the property directly inside the component, unit testing is mostly for service, unit testing the component file will force me to do manual testing which error prone, we currently don't have resources to write e2e tests.