I am choosing between DOM testing and component class testing. And ran into some questions hope you could help me with them.

1. The Pros and Cons are to some point clear to me, yet I am noticing that nearly all the libraries in Github use DOM testing, is there a reason behind that :D ?.
2. With DOM testing, is there any possibility to get html coverage ( similar to code coverage with Karma/Istanbul)?.
3. Some guy mentioned that, in case of DOM testing, I am testing a scenario not code, is that right, if yes how does that effect my expectations (when to be satisfied with my tests)
4. In code review, what would you look for (other than code coverage) to make sure that the new stuff added is totally tested?

Thanks in advance :).

CodePudding user response：

When it comes to testing frontends, ideally, you want to test what the end user will be experiencing. So in response:

The Pros and Cons are to some point clear to me, yet I am noticing that nearly all the libraries in Github use DOM testing, is there a reason behind that :D ?.

DOM testing allows you to test interactions, which is probably why most libraries do it. It ensures that the end user's interactions perform the expected operations.

With DOM testing, is there any possibility to get html coverage ( similar to code coverage with Karma/Istanbul)?.

I don't think there is a comparable "HTML coverage" report like Karma/Istanbul, and I don't know that it would be feasible/helpful. When testing an angular component, the entire component is rendered in the testing browser - so there wouldn't be a very helpful metric of how much HTML was rendered or tested.

Some guy mentioned that, in case of DOM testing, I am testing a scenario not code, is that right, if yes how does that effect my expectations (when to be satisfied with my tests)

Yes - you are testing scenarios and interactions with DOM testing. You setup the scenario that a user may encounter and you test what actions the user has access to in that scenario.

In code review, what would you look for (other than code coverage) to make sure that the new stuff added is totally tested?

As long as you ensure that your tests are useful and provide value (they correctly assess if a user's interactions achieve the desired goal), your code-coverage should be sufficient. In addition to components, services, directives, etc. unit tests (my recommendation), you can also look into E2E tests with a framework like Cypress.

Testing Angular is a great resource to understanding how to think about testing in Angular. For example, it suggests that instead of testing internal and private methods directly on a component, you unit test the component's API - inputs, outputs, clicks, etc. that implicitly test those internal and private methods.