3

While developing applications with Angular (2,4,5,...) people are using a lot of *ngIf="whatever_condition" and less often also ngSwitch

However I have not seen any tooling that would be able to provide information about how much of that code was actually tested..

Obviously for Typescript files there's istanbul loader to get the coverage, but I believe it gives false picture of having a high coverage in a sense that a big chunk of the logic sits in the views for which there is no measurement.. I.e. if I have branch coverage of 90% on Typescript, but still have two times as much branches in the views, the actual coverage might be somewhere between 45% and 90%.

Is there any tooling out there that is able to measure code coverage for Angular views and show it in a meaningful way?

kubal5003
  • 7,186
  • 8
  • 52
  • 90
  • [Webstorm has code coverage](https://www.jetbrains.com/help/webstorm/code-coverage.html) however I've not used it. – lloyd Dec 05 '17 at 08:30
  • I don't really see how helpful this is.. Angular templates are compiled to javascript and there's no link between what is executed and the templates themselves.. Unless I'm wrong and you just need to know how to configure it.. – kubal5003 Dec 05 '17 at 12:19
  • How complex is the logic in your `*ngIf="whatever_condition"`. [code coverage for karma](https://stackoverflow.com/questions/44463706/code-coverage-for-angular-2) typically considers the files where the logic sits. [It's a code smell](http://daginge.com/technology/2013/12/14/testing-angular-templates-with-jasmine-and-karma/) and you should consider placing whatever_condition in the controller as you shouldn't need to test the view. – lloyd Dec 06 '17 at 00:40
  • I fully agree that by all normal standards this is a code smell, however that's the 'Angular 2+ way' and I believe I also need to find a relevant source for this statement.. – kubal5003 Dec 06 '17 at 16:28

1 Answers1

0

I have not looked into coverage on the template, but, you could look into component- vs unittest.

I usually do the following: 

it('',()=>{
  component.whatever_condition = true;
  const el = fixture.debugElement.query(By.css('someElement'));

  fixture.detectChanges();

  expect(el).toBeDefined();
});

I realise this doesn't give you coverage, but it provides tests for your template.

NB consider if an e2e test is what you need instead

I hope it helps

kodeaben
  • 1,829
  • 3
  • 24
  • 33
  • 2
    Sorry, but the question was about the coverage measurement and not testing the views. I am testing 'the Angular way' which is exactly what you suggested, but the problem is that I don't know what is tested and what is not just by looking at a tool. I also know that even the code coverage is not really case coverage, but that's different discussion.. – kubal5003 Dec 05 '17 at 12:16
  • To me it seems like you want to test something that is not your responsibility. Updating your view based on data, via model-binding is what Angular does and so it it beyond the scope of you tests. It is ok to assume that the framework does what is expected of it. – kodeaben Dec 05 '17 at 14:32
  • 2
    I am not testing if Angular is working correctly.. If I paraphrase what you're saying - testing conditions I write in Typescript is not my responsibility, because Typescript is guaranteed to execute them correctly.. I'm hoping you should now see my point :) – kubal5003 Dec 06 '17 at 16:25
  • 1
    Can you explain why? I was under the impression that I as a developer should be testing all the code that I'm writing and I suppose that you are doing it too (based on your answer). However you do not seem to be interested if you did actually cover the code you have in the views.. I get the fact that just by reading the code you can tell if you have sufficient tests, but I personally would still prefer to have some automated metric on it.. – kubal5003 Dec 07 '17 at 16:46
  • My point is that you don't (shouldn't) have code in the view. The `*ngIf` is not your code, it is an angular directive and it's not your job to test Angulars code just like you don't test if a for-loop does its job – kodeaben Dec 08 '17 at 11:54