Couverture de code par les tests en TypeScript : comment arrêter de deviner et commencer à mesurer
\n\nImaginez que vous assemblez un mécanisme complexe avec de nombreux engrenages. Vous êtes sûr d'avoir tout assemblé correctement, mais dès que vous appuyez sur le bouton « Démarrer », un grincement se fait entendre et le mécanisme se bloque. Une situation familière ? Dans le monde du développement TypeScript, ces « mécanismes » sont nos applications. Et la couverture de code par les tests est l'assemblage de contrôle qui montre quelles pièces nous avons vérifiées et lesquelles nous avons laissées au hasard.
\n\nDe nombreux développeurs sont sceptiques quant aux métriques de couverture : « La course aux pourcentages est un mal », « Une couverture à 100 % ne garantit pas l'absence de bugs ». Et c'est vrai. Mais, comme tout outil, la couverture de code peut être utile ou nuisible – tout dépend de la façon dont on l'utilise. Dans cet article, nous allons voir comment mesurer correctement la couverture en TypeScript, quels outils existent pour cela et comment ne pas faire des métriques une fin en soi.
\n\nQu'est-ce que la couverture de code et pourquoi TypeScript ne fait pas exception
\n\nLa couverture de code (code coverage) est une métrique qui montre quelle partie du code source a été exécutée pendant les tests. En TypeScript, qui est compilé en JavaScript, la mesure de la couverture se fait au niveau du code compilé, mais les outils modernes savent afficher joliment les résultats en termes de code TS source.
\n\nLes principales métriques de couverture à connaître :
\n\n- \n
- Line coverage — pourcentage de lignes de code qui ont été exécutées au moins une fois. \n
- Branch coverage — pourcentage de branchements (if/else, switch, opérateurs ternaires) qui ont été testés. \n
- Function coverage — pourcentage de fonctions/méthodes qui ont été appelées. \n
- Statement coverage — pourcentage d'instructions individuelles (opérateurs) dans le code. \n
Pour les projets TypeScript, la branch coverage est particulièrement importante, car le typage strict ne protège pas des erreurs logiques dans les conditions. Vous pouvez typer correctement toutes les variables, mais oublier le cas où un tableau est vide alors qu'une fonction attend au moins un élément.
\n\nOutils pour mesurer la couverture en TypeScript
\n\n1. Istanbul (nyc) — le grand-père de toutes les couvertures
\n\nIstanbul est l'outil le plus populaire pour mesurer la couverture du code JavaScript et TypeScript. Il fonctionne comme un utilitaire indépendant (via le package nyc) ou comme un module intégré dans les frameworks de test.
Pour commencer à travailler avec Istanbul dans un projet TypeScript, installez :
\n\nnpm install --save-dev nyc typescript ts-node\n\nCréez un fichier .nycrc pour la configuration :
{\n "extends": "@istanbuljs/nyc-config-typescript",\n "all": true,\n "include": ["src/**/*.ts"],\n "exclude": ["src/**/*.test.ts", "src/**/*.spec.ts"],\n "reporter": ["text", "html", "lcov"],\n "check-coverage": true,\n "branches": 80,\n "lines": 85,\n "functions": 85,\n "statements": 85\n}\n\nExécution des tests avec couverture :
\n\nnpx nyc mocha --require ts-node/register src/**/*.test.ts\n\nIstanbul génère des rapports dans la console (text) et sous forme de pages HTML, où le code couvert est surligné en vert et le code non couvert en rouge. C'est très visuel.
\n\n2. Jest — tout-en-un
\n\nJest est le framework de test le plus populaire pour TypeScript. Il inclut déjà un outil de couverture intégré basé sur Istanbul. Vous n'avez rien à installer de plus.
\n\nConfiguration de base dans jest.config.ts :
import type { Config } from 'jest';\n\nconst config: Config = {\n preset: 'ts-jest',\n testEnvironment: 'node',\n collectCoverage: true,\n coverageDirectory: 'coverage',\n coverageReporters: ['text', 'html', 'lcov'],\n collectCoverageFrom: [\n 'src/**/*.ts',\n '!src/**/*.test.ts',\n '!src/**/*.spec.ts',\n '!src/types/**/*.ts'\n ],\n coverageThresho