đą 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:
- EN Rethinking JavaScript Test Coverage
- EN Comprehensive and exhaustive JavaScript & Node.js testing best practices (January 2021)
- EN Writing Tests With Fastify and Node Test Runner
- EN How to create E2E tests in Node.js with no frameworks - step by step!
- EN Test Assertion Styles in JavaScript
đ 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