tests(JS): Mise en place tests unitaires et couverture pour code JS/TS

[adrienjoly]

Pierre et moi allons ajouter des tests unitaires aux fonctions JavaScript employées par le map-reduce exécuté sur MongoDB, et nous voulons mesurer l'évolution de la couverture du code par ces tests.

À cette fin, je propose dans cette PR:

• l'intégration du service Codacy (gratuit pour les dépôts open source) pour suivre l'évolution de la couverture
• l'usage de istanbul/nyc pour générer le rapport de couverture lors de l'exécution des tests JS/TS
• l'usage d'Ava et ava-ts pour écrire et exécuter nos tests unitaires en TypeScript sans nécessiter de transpilation
• et l'exécution automatique des tests avec mesure de couverture sur l'environnement de CI

Pour tester ces nouvelles fonctions:

$ cd dbmongo/js
$ nvm use
$ npm install
$ npm test
$ npm run test:coverage
$ rm -rf ./coverage

...et, quand cette PR sera fusionnée dans master, nous pourrons suivre l'évolution de la couverture des tests depuis cette page: https://app.codacy.com/gh/signaux-faibles/opensignauxfaibles/dashboard

[adrienjoly]

Ce fichier contient le numéro de version de Node.js nécessaire pour que les nouveaux tests puissent s'exécuter.

Depuis le répertoire dbmongo/js, il suffit de taper nvm use pour utiliser cette version. (voir nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions)

[adrienjoly]

Ce fichier contient la configuration de Istanbul/nyc, l'outil qui permet de générer un rapport de couverture (coverage) lors de l'exécution des tests JavaScript/TypeScript.

[adrienjoly]

Pour exécuter ces tests, il suffit de taper npm test depuis dbmongo/js.

[adrienjoly]

Cette ligne est nécessaire pour que la fonction soit visible après son importation dans un test exprimé en TypeScript, mais elle est incompatible avec jsc.

=> Solution choisie: essayer d'exporter la fonction pour TypeScript, et faire retirer ce bloc par jsLoad lors du bundling. (cf https://github.com/signaux-faibles/opensignauxfaibles/pull/43/files#diff-a688410c05f14479ef1f74e809527503R53)

[adrienjoly]

Pour info, avant de décider d'utiliser Node et Ava-ts, j'avais considéré deux autres solutions. Voici mes notes d'évaluation de ces solutions:

Solutions pour refactorer et tester fichiers JS/TS

Deno

Liens

• (1) https://blog.logrocket.com/deno-1-0-what-you-need-to-know/
• official homepage: https://deno.land/
• Deno Third Party Modules
• denolib/awesome-deno: 🎉A curated list of awesome things related to Deno

PROs

• officially scheduled for release on May 13 (1)
• security: no access to I/O by default (1)
• has a standard library based loosely on the one provided by Golang (1)
• uses strict mode by default => alert user about sloppy coding practices (1)
• built-in test runner (1)
• built-in code formatting, following Prettier 2.0 rules (1)
• deno bundle to generate a JS bundle + source map from TS files (1)

CONs

• ⚠ no test coverage feature yet (1) => watching feature-request: first-class test-coverage support denoland/deno#106
• linter is not ready yet (1) => watching Add "deno lint" subcommand denoland/deno#1880
• vscode extension does not support Deno debugging yet (1)

Questions ouvertes (TODO)

• can we quickly run our JS tests and re-generate our jsFunctions bundle with Deno?

---

Rome

Liens

• (1) https://romejs.dev/
• (2) https://romejs.dev/docs/introduction/installation/

PROs

• similar philosophy to Deno: all-inclusive and opinionated JS/TS toolkit => can format, lint, run and bundle JS code (1)
• coverage is supported (feature-request: first-class test-coverage support denoland/deno#106 (comment))

CONs

• still experimental => ⚠️ not suitable for production yet (1)
• must be built from source + runs on top of Node.js (2)
• documentation is very minimalistic (2)

Jest ?

Ma confiance en Jest est relative, pour les raisons suivantes:

• malgré leurs efforts, Jest est assez lourd: 49 MO (cf https://jestjs.io/blog/2020/05/05/jest-26) => 2 MO minifié, contre 500 KO pour Ava (cf https://bundlephobia.com/[email protected] et https://bundlephobia.com/[email protected])
• j'ai eu la mauvaise surprise de constater que les tests échouaient silencieusement et à cause d'un timeout lorsqu'une exception arrivait dans un bloc beforeAll ou afterAll (Tests are run even when beforeAll throws error jestjs/jest#2713 (comment)) => ça ne m'inspire pas confiance.
• enfin, quitte à utiliser un test runner basé sur Node et compatible avec TypeScript, je n'ai eu que de bonnes expériences avec Ava et ava-ts, et il me semble que ceux-ci sont adaptés à notre projet.