Salut les kheys,

Je viens vous poser une petite question parce qu'après pas mal d'errances sur différents blogs et tutoriels je cerne toujours pas très bien l'intérêt de tester son code via des frameworks de tests - typiquement php unit testing. Je suis sous Symfony et quand y'a une couille dans mon code je me tape une erreur directement, pas besoin d'avoir à tester mon code. Possible d'expliquer ?

J'ai cru comprendre que ça servait notamment pendant la phase de prod, quelqu'un peut confirmer éventuellement ?

Outre-mesure si vous avez des tutos/blogs qui expliquent bien le principe je suis preneur.

Salut,

Les tests unitaires sont très importants, tu as même une méthode de développement où tu écris tes tests avant même de développer (Test-Driven Development (TDD))

Pour plusieurs raisons les tests sont essentiels :

1. Le code est vivant et donc, une fonction par exemple, va être amenée à évoluer au cours de la vie d'une app, non tu ne feras pas des tests manuels constamment, tu vas préférer écrire des tests qui permettront de contrôler la non-régression d'une fonction automatiquement
2. Pour tester les comportements possibles d'une fonction en fonction des inputs que tu lui donnes
3. Pour la mise en place de CI/CD

Les tests sont essentiels pour une fiabilisation du code, un code fiable sera plus simple à faire évoluer, à maintenir, à comprendre et tu pourras plus aisément faire des migrations (version de PHP ou de Symfony par exemple)

Une fois j'ai développé un formulaire qui générait un PDF pré-rempli avec toutes les saisies.

Et à chaque fois, pour vérifier que le PDF se générait comme il faut, je re-re-re-soumettais le formulaire pour faire du débuggage.

Et c'est là que j'ai ressenti pour la première fois l'utilité d'avoir un test unitaire. Ca m'évitait d'avoir à remplir le form depuis le début à chaque fois que je voulais tester la génération du PDF

Le test uniaire permettait directement de tester la fonction de génération du PDF sans avoir à soumettre le form.

J'ai mis du temps à écrire le test unitaire mais paradoxalement ça m'a finalement fait gagné du temps.

Le 20 mai 2021 à 00:41:35 :
Salut,

Les tests unitaires sont très importants, tu as même une méthode de développement où tu écris tes tests avant même de développer (Test-Driven Development (TDD))

Pour plusieurs raisons les tests sont essentiels :

1. Le code est vivant et donc, une fonction par exemple, va être amenée à évoluer au cours de la vie d'une app, non tu ne feras pas des tests manuels constamment, tu vas préférer écrire des tests qui permettront de contrôler la non-régression d'une fonction automatiquement
2. Pour tester les comportements possibles d'une fonction en fonction des inputs que tu lui donnes
3. Pour la mise en place de CI/CD

Les tests sont essentiels pour une fiabilisation du code, un code fiable sera plus simple à faire évoluer, à maintenir, à comprendre et tu pourras plus aisément faire des migrations (version de PHP ou de Symfony par exemple)

Donc si je comprends bien tu testes des fonctions pour vérifier qu'elle réagissent bien comme on leur demande juste qu'à la place de tester manuellement tu testes via des lignes de code. D'accord. En essayant de me document sur le TDD je suis tombé sur cet article et l'auteur semble dire que PHP Unit Testing c'est le bas du panier concernant le testing et il donne Selenium comme le testing hight-tech, tu confirmes ? J'ai entendu dire que Selenium était une sal*perie à utiliser parce que vachement fastidieux, compliqué et vieux.

Pour ceux comme moi qui sont en quête de compréhension sur le testing je viens de regarder cette vidéo https://www.youtube.com/watch?v=a5ZKCFINUkU et dans les 30 dernières secondes la personne met bien en scène ce à quoi peut potentiellement servir un test.

l'auteur semble dire que PHP Unit Testing c'est le bas du panier concernant le testing et il donne Selenium comme le testing hight-tech, tu confirmes ?

C'est absolument pas les mêmes types de tests, celui qui a écrit ça n'a rien compris. Avec Selenium tu fais plutôt des tests fonctionnels (functional test)
C'est surtout qu'en général si tu veux une bonne couverture il te faut les deux, mais les tests unitaires sont plus important selon moi.

Si je devais donner un exemple grossier je te dirais que les tests fonctionnels sont là pour confirmer que si tu cliques sur le bouton ici tu as bien la pop-up liée qui s'ouvre alors qu'un test unitaire va tester du code logique. (que ma fonction retourne bien ceci en fonction de cela, ...)

Les tests unitaires te permettent en effet de détecter principalement les régressions dans ton code : en faisant tourner ta suite de tests à chaque fois que tu développes quelque chose, tu peux voir automatiquement et instantanément (quasiment) que tu as pété quelque chose, c'est un avantage énorme, surtout quand il s'agit d'effets de bord que tu n'avais pas prévu.

Selenium, et d'autres technologies plus récentes comme Cypress permettent principalement le test E2E (End-to-End) : tu simules un utilisateur qui clique sur ton interface, tu vérifies que tout fonctionne bien, et encore une fois ça te permet de voir quand d'un coup quelque chose ne fonctionne plus.

En général on va essayer de coupler les tests unitaires et autres vérifications du genre à de l'intégration continue (CI) et de la livraison continue (CD) pour qu'à chaque fois qu'on veuille mettre notre code en ligne ça fasse tourner les tests etc, et que ça ne déploie pas s'il y a un souci, histoire que le code en ligne soit toujours stable et propre.

Développer en testant ça a des avantages énormes qu'on peut mesurer :
- ça réduit le nombre de bugs par application
- ça réduit le stress des développeurs (mais là on parle plus du milieu "entreprise" du coup fatalement)
- ça permet de mieux apprendre et intégrer de nouveaux savoirs
- ça permet de mieux se représenter et concevoir le fonctionnement de son application (tu la réfléchis formellement en en écrivant les tests qui servent de spécifications)

Cela dit ça n'a pas que des avantages :
- ça impacte négativement à court et moyen terme la vélocité de développement (on développe moins vite)
- le TDD n'a en fait pas ou peu d'impact, ce qui a l'air de compter quand on mesure c'est d'écrire des tests, avant ou après ça change pas ou peu.

Merci pour vos réponses les kheys. Je tag en résolu.

- le TDD n'a en fait pas ou peu d'impact, ce qui a l'air de compter quand on mesure c'est d'écrire des tests, avant ou après ça change pas ou peu.

Alors si, le TDD a un énorme impact pour 2 raisons :

1. La plus importante, le design du code. Lorsqu'on écrit le test avant, on doit "consommer", "utiliser" l'unité testée. Plus l'unité testée est facile à utiliser, plus les tests seront simples à écrire, et plus le design du code sera propre. En écrivant les tests après, le code a déjà été écrit et donc, ce sont les tests qui s'adaptent au code. Parfois même, il est impossible d'écrire de tests (unitaires) pour un code déjà écrit (par exemple une API utilisée en dur, sans DI).
2. Le coverage. Faire du TDD uniquement signifie que tout le code écrit est testé, par définition. On réduit considérablement le nombre de régressions sur le long terme.

Alors qu'on soit bien claire : je pense que le TDD est préférable à l'ITLD (Iterative Test-Last Development). Cela dit, je ne veux pas utiliser une méthodologie sans me baser sur rien, alors j'ai fait une revue de la littérature scientifique pour voir ce qu'on mesurait concernant le TDD, l'ITLD et le no-test, et il se trouve que le résultat de cette compilation d'articles scientifiques est contrastée sur certains sujets, mais que pour le moment (j'essaye d'y rajouter régulièrement des sources quand j'ai le temps) une des conclusions est clairement qu'écrire les tests avant ou après avoir écrit le code n'est pas le facteur le plus déterminant dans les critères que tu cites.

Je nuancerais cependant sur un point : on oppose plus souvent le TDD à "pas de tests" qu'à l'ITLD, et oui clairement dans ce cas les bénéfices sont monstrueux. Quand on le compare à l'ITLD cependant certains facteurs ne changent pas ou peu :
- nombre de defects (même si là j'ai peu de points de comparaison avec l'ITLD)
- qualité externe (on trouve même certaines études dans laquelles la qualité externe est supérieure pour l'ITLD, même si je parierais plus sur des fluctuations statistiques marginales)
- qualité interne (complexité algorithmique, architecture, design patterns, etc.), et là ça s'explique très bien par un facteur : personne n'effectue correctement la dernière étape du TDD qui est le refactoring, et donc une fois testé le code ne bouge plus.

Cela dit tout n'est pas sombre et le TDD en lui-même a des avantages indéniables :
- amélioration de la confiance des développeurs dans leur code et diminution du stress
- amélioration de l'apprentissage et de la représentation conceptuelle du code

On peut noter également qu'un meilleure découpage des tâches en amont permet de réduire les defects et d'augmenter la qualité interne, peut-être que le TDD favorise ce découpage mais là encore j'ai peu de données.

Ce que je conclue de ça, c'est que si quelqu'un ne teste pas son code, mieux vaut le faire tester avant ou après son écriture en premier lieu en lui laissant le choix, avant d'arriver au TDD, car c'est surtout la présence de tests qui amène le plus de bénéfices. Ensuite, quand on en arrive au TDD il est surtout nécessaire de ne pas négliger le refactoring (avec par exemple de la peer review systématique, ce sur quoi je fais actuellement des recherches de la même sorte) pour avoir encore de grands bénéfices.

Encore une fois : je suis totalement pour le TDD, je dis juste que s'il faut faire des choix, ce n'est pas le plus gros facteur d'amélioration, c'est tout.