0

I have a TypeScript project that uses Visual Studio's "Combine JavaScript output into file" option to create a single .js file containing all my application's code (excluding libraries). I'm using the Chutzpah Test Adapter to integrate and run Jasmine unit tests. If I run a code coverage analysis with no tests, the tool reports I have 23% test coverage:

Code coverage statistics

What is causing this inflated statistic?

My current theory is that when Chutzpah runs my code (app.js) in order to define all of the classes to be used in the tests, blanket.js (which is what Chutzpah uses under the hood to get code coverage statistics) sees that these lines are being run and counts them as a "covered line".

Is there a way to only include lines that are hit during a test (as opposed to before the test, for setup purposes) towards the final code coverage statistic? Or is this inflated number caused by something else?

Here's my chutzpah.json:

{
    "Compile": {
        "Extensions": [ ".ts" ],
        "ExtensionsWithNoOutput": [ ".d.ts" ],
        "Mode": "External"
    },
    "References": [
        { "Path": "initialize.js" },
        { "Path": "./MyApp/lib/jquery-1.11.2.min.js" },
        { "Path": "./MyApp/lib/jquery-ui.min.js" },
        { "Path": "./MyApp/lib/knockout-3.3.0.js" },

        /* other references here.... */

        { "Path": "./MyApp/app.js" }
    ],
    "Tests": [
        { "Includes": [ "**/*.ts" ], "Excludes": [ "**/*.d.ts" ] }
    ],
    "CodeCoverageIncludes": [ "*app.js*" ],
    "TestFileTimeout": 100000
}
Nathan Friend
  • 12,155
  • 10
  • 75
  • 125
  • This question might be related: http://stackoverflow.com/questions/37298684/chutzpah-coverage-result-smaller-than-100-due-to-private-methods – Stefan Dec 14 '16 at 13:55

1 Answers1

2

TypeScript generates a reasonable number of immediately invoked function expressions. The fact that these run as soon as the file is loaded means they are covered no matter what. If you don't get an error, that 22% of your code works - no need to write any tests for that.

In C# or Java this wouldn't happen because a class would have 0 coverage if you haven't instantiated it - but in TypeScript, some of the code generated for modules and classes will run when you load the file.

Here is an indication of likely lines that will be covered for this class:

class Example {
    doSomeWork() {
        return 50;
    }
}

Coverage:

✓ var Example = (function () {
✓    function Example() {
✓    }
✓    Example.prototype.doSomeWork = function () {
✗       return 50;
✓    };
✓    return Example;
✓ })();

As you can see, there are quite a few things that will "run" just by loading the file. The actual behaviour (the function that returns a value) is not covered.

I would classify these lines of code in a similar way to properties on a plain object - you wouldn't want to write a specific test to cover them - but they'll get covered naturally.

You can't really adjust your reporting for this, but suffice to say you should be interested in the 78% rather than the 22%.

Fenton
  • 241,084
  • 71
  • 387
  • 401
  • Thanks for the response. So it sounds like there isn't an easy way to eliminate the extra noise and get an accurate coverage statistic? Without knowing the details of `blanket.js`, it seems like it could listen for coverage only *while* the tests are being run instead of the listening during the entire test run (including setup). – Nathan Friend Jul 30 '15 at 18:13