Qu'est-ce qu'un test unitaire ?

[@GuillaumeDuhan1]

Merci Bryan de te concentrer sur un sujet aussi important. Pourtant c’est encore pareil, beaucoup de développeurs n’écrivent jamais de tests unitaires; moi le premier. Mais c’est un sujet qu’il faut explorer et développer tout de même !

[@KorxKlesk]

La meilleure approche, je pense, pour aborder le test unitaire est le TDD. Et honnêtement le jeux en vaut la chandelle :). Ça évite de devoir se contraindre à écrire des tests une fois la feature développée ( ce qu'on ne fera pas hein... on le sait :D ).

[@DevTheory]

Si vous souhaitez enfin créer vos premiers tests unitaires sur vos projets JS, alors suivez le nouveau cours de DevTheory : go.devtheory.fr/cours-unit-testing?

[@SaaSMakers]

Les tests ont vraiment changé ma manière de coder depuis 4 ans. Cela m’a aussi permis de me passer de Postman ou Insomnia completement car on teste directement nos endpoints d’API depuis nos tests. Du coup on a plus que un soft pour coder: VSCODE. On gagne clairement du temps sur le long terme, mais il faut se faire violence au debut. (On est aussi rassure quand de nouvelles personnes touchent au code car on a nos tests pour garantir que tout se passe bien)

[@DevTheory]

Très bonnes remarques ! Merci de ton retour 🙏

[@KorxKlesk]

La définition des tests E2E mériterait d'être un peu précisée. Un test E2E n'est pas forcément lié à une librairie comme Cypress ou Selenium et ne simule donc pas forcément un comportement utilisateur. Dans ce cas précis on est davantage sur du test fonctionnel. Par exemple on peut tout à fait faire du test E2E en python via pytest en appelant une route REST de façon à tester la réponse et donc l’exécution complète de la chaîne derrière. Sur une API, on aura jamais de tests fonctionnels au sens "Cypress" du terme, ils seront réservés au front qui consomme l'API. Autre point intéressant à indiquer, c'est le coût des différentes types de tests en terme de charge. Les tests unitaires sont en général les plus rapides a exécuter car on ne montera pas de BDD ou d'éléments complexes, les tests d'intégrations seront plus gourmands car là on commencera potentiellement à écrire des datas et enfin les tests E2E seront ceux qui consommeront le plus de ressources et seront en général les plus longs a exécuter en local ou dans une CI. En général, pour les tests E2E on va cibler en priorité les chemins critiques d'une app car l'investissement est plus lourd.

[@DevTheory]

Merci pour tes précisions très intéressantes ! 🙏

[@filymsakine7693]

Merci beaucoup

[@oliviasiewe2814]

Et qu’en est t’il de tests unitaires en C sur CLion svp ?

[@Xerxes92]

Jest fait aussi du code coverage grâce à : Jest --coverage

[@DevTheory]

Yep, et c'est Istanbul qui est inclus à Jest pour cette commande fonctionne ✅

[@u.tassinari2916]

Il y a des libraries de test pour react ?

[@DevTheory]

Oui pas mal, recherche "react testing library" sur google ✅