SonarQube reports 0% coverage for interface files, whereas interfaces can't actually be tested.

[JaSpr]

Karma/Istanbul correctly leaves out interface files, because they are inherently not testable, however the SonarTsPlugin lists those interface files as having 0% coverage, which is bringing our overall coverage percentage down below the 90% coverage required by our devops team to deploy.

accordion.interfaces.ts

export interface AccordionHeaderConfig {
  headings: string[];
  subheadings: string[];
}

Istanbul

(showing coverage for all relevant files in directory)

File            || Statements   || Branches || Functions    || Lines 
accordion.component.ts  || 100% | 26/26 || 80% | 4/5    || 100% | 8/8   || 100% | 22/22

SonarQube

(showing coverage for all relevant files in directory)

FILE            || COVERAGE || UNCOVERED LINES  || UNCOVERED CONDITIONS
accordion.interfaces.ts || 0.0%     || 4            || –
accordion.component.ts  || 90.3%    || 0            || 3

[nixel2007]

AFAIK this plugin does not count coverage at all. @pablissimo please, correct me, if I'm wrong

[JaSpr]

Additionally, some discussions with other teams at my organization revealed that the better practice is to NOT create interface.ts files (specifically because they can't be tested), and to instead declare interfaces in a typings file. This allowed us to drop all of those interface files with 0.0% coverage

[Pablissimo]

Interfaces in a typings file isn't something I've come across, I'm stealing that idea for work!

The trouble is that the plugin knows nothing about TypeScript as a language, beyond how to count commented lines. I was going to integrate basic lexing to be able to detect code that's not really executable (like interfaces, or the uncovered conditions you get in class and module definitions) but news then came that there'll be an official TypeScript plugin built by SonarSource and I didn't want to commit time to doing it if it was going to immediately be made redundant by an official plugin. At the minute that official plugin doesn't seem to do coverage that I can tell, just linting so maybe it's time to see.

The suggestion of using the TypeScript compiler itself to determine this stuff came up and is a goody, so still happy to explore that assuming there's no plans on the official plugin to do coverage.

[leonardonelson91]

@nixel2007 I'm also not able to pull any coverage values from my lcov file, even after specifying it's path. Is there anything else required to make it work @Pablissimo ?

Logs: INFO: Sensor Combined LCOV and LOC sensor [typescript] INFO: Analysing C:\fakepath\tests\coverage\ts\lcov\lcov.dat INFO: Sensor Combined LCOV and LOC sensor [typescript] (done) | time=494ms INFO: Sensor JavaScript Squid Sensor [javascript] INFO: 1 source files to be analyzed INFO: Unit Test Coverage Sensor is started INFO: 1/1 source files have been analyzed INFO: Integration Test Coverage Sensor is started INFO: Overall Coverage Sensor is started INFO: Sensor JavaScript Squid Sensor [javascript] (done) | time=92ms INFO: Sensor Zero Coverage Sensor INFO: Sensor Zero Coverage Sensor (done) | time=65ms

[nixel2007]

You can check my vscode+istanbul lcov setup here - https://github.com/xDrivenDevelopment/vsc-language-1c-bsl