Ir al contenido principal

Tests coverage in Typescript

Learn how to apply test coverage to your Typescripts projects.

Say that you have a bunch of Typescript projects that also have a bunch of unit tests per project. Now you want to go one step further, you want to know what is the coverage of those tests.

In simple terms, test coverage measures the percent of your codebase that is being covered by tests, so the higher the coverage the safer your code is (assuming that the tests were properly coded).

To start, you will need to install Istanbum command line interface (package nyc) and its pre-configuration for typescript projects (package @istanbuljs/nyc-config-typescript) by running this command:

$ npm install --save-dev nyc \
@istanbuljs/nyc-config-typescript

Once installed, create a nyc configuration file called .nycrc (optionally you can use the .json extension and call it .nycrc.json) with this content:

// .nycrc file
{
  "extends": "@istanbuljs/nyc-config-typescript"	
}

Finally, and assuming you had a script called test in your package.json file, create a new script called coverage with this content:

// package.json file
{
  ...
  "scripts": {
    ...
    "coverage": "nyc npm run test"
  }	
}

To check that everything is correct, run the new script (npm run coverage) and you should see your tests being executed and, after them, a coverage report being printed in the console.

Understanding the coverage report

The coverage report shows the percent of the code being covered by the tests from four different perspectives:

  • The statements being covered (% Stmts)
  • The branches being covered (% Branch), meaning a branch every code bifurcation as when you use a if statement.
  • The functions being covered (% Funcs)
  • The lines of code being covered (% Lines)

More importantly, the coverage report also states specifically what lines or each file are not covered by tests (Uncovered Line #s).

Checking the coverage values

nyc support the possibility of checking that certain coverage metrics are above certain limits and, in case of being below, triggering an error. This is useful if you are applying coverage checks in a pre-commit process, therefore avoiding commiting code that did not match a certain quality degree.

To state coverage checks, set the .nycrc (or .nycrc.json) configuration file in this way:

// .nycrc file
{
  "extends": "@istanbuljs/nyc-config-typescript",
  "check-coverage": true,
  "branches": 70,
  "lines": 70,
  "functions": 70,
  "statements": 70
}

Specifically in the example above, a limit of 70% is stated for all the metrics, so if any of them fall bellow that value nyc will trigger an error.

Have in mind that coverage checking is only applied to the metrics of all files, so if you have a project with two files, one of them with a statement coverage of 60% and the other with a statement coverage of 90%, since the average of all two files is 75% the coverage check will pass, even having a file with the metrics below the threshold.

Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what  linting  is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld {      using System;      public class Program      {           public static void Main(string[] args)           {                Console
Publicar un comentario
Leer más

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define
Publicar un comentario
Leer más

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.
Publicar un comentario
Leer más