🐢 Node.js

📊 Test unitaire et coverage

Réaliser des tests unitaires est une bonne solution pour s’entraîner et mieux comprendre comment un code X ou Y fonctionne (et vous force à étudier diverses fonctionnalités de JavaScript). Néanmoins il peut vite être difficile de s’y retrouver dans un écosystème où le choix de framework/lib est vaste :

Mocha, Ava, Japa, Tape et beaucoup d’autres…

Certains auront l’avantage d’être plus complet (plus lourd) et d’autres plus simpliste. Quelquefois cela se joue sur différents détails comme le choix de la librairie d’assertion (Chai.js par exemple) ou bien l’inclusion du coverage par défaut.

[!WARNING] L’utilisation de Jest pour du testing back-end n’est pas recommandé (mauvaise performance, ré-écriture des globals ..).

Lorsque le coverage n’est pas inclus par défaut il vous faudra potentiellement réfléchir à l’inclure vous même avec C8 (librairie utilisant le coverage natif de V8 Engine). C8 est notamment capable d’offrir le coverage même quand le code est exécuté au travers de différents child process (ou worker).

Talks et articles:

💃 Méthodologies

De nos jours, il n’est pas rare que les juniors soient forcés à appliquer des méthodologies sans que leur mentor n’apporte de réelle réflexion ou arguments: “c’est comme ça si tu veux devenir un bon développeur”.

Je pense qu’apprendre à écrire des tests est essentiel pour un développeur (et que c’est plutôt sur cette fondation commune que nous devons nous appuyer pour guider les débutants).

Il est important de conserver un fort esprit critique sur les différents choix que l’on essayera de vous imposer comme des pratiques qu’il faut constamment appliquer car celles-ci vous enferment certainement dans une bulle idéologique (ce qui n’est pas une invitation à ne rien faire).

Par exemple, apprendre TDD et autres méthodologies sera bénéfique pour ajouter des cordes à votre ARC (surtout sur certains projets où leur pratique sera une plus- value). Néanmoins, cela ne veut pas dire qu’elles sont absolues à l’intégralité des contextes et projets ou qu’il ne faut pas en débattre.

Quelques liens pour vous faire une “opinion”:

FR BDD, DDD, ATDD et TDD expliqués !
EN Why Most Unit Testing is Waste
EN Test-induced design damage.
EN TDD is dead. Long live testing.
EN [TW Hangouts Is TDD dead?.](https://www.youtube.com/watch?v=z9quxZsLcfo)
EN TDD, Where Did It All Go Wrong
FR LMHB #5: KEEP CALM & TDD ! FEAT. LIODA (Test-driven development)

Dans notre domaine nous parlons très peu de cela tellement ils sont sujets à des tensions extrêmes entre nous. Je trouve quelquefois dommage que l’on ne puisse pas discuter sans y amener son lot de toxicité et d’ego.

⬅️ 🐢 Node.js: WebSocket | ➡️ 🌟 Les différents modules core: Console