Discussion :

[Lucas Panny]

Bonjour,

Je travaille en régie pour le compte d'une SSII et on me demande d'utiliser la technique Test Driven Development
Et là je ne comprends pas comment dois-je procéder? C'est quoi un test unitaire, n'est-ce pas un métier du testeur?

En cherchant sur Google, je tombe souvent sur PHPUnit mais quelqu'un peut-il m'expliquer à quoi ça sert?

[grunk]

Cela sert à tester chaque partie de ton code.

A chaque classe va correspondre différents tests (en général un ou plusieurs test par méthode) qui vont garantir que ton application fonctionne correctement.

PAr exemple si tu as une méthode addition($a,$b). Tu auras un test additionTest(5,5); qui devra vérifier que le retour de addition() correspond bien a 10

Ces test sont en général à lancer après chaque modification du code pour confirmer que cette modification n'impacte pas négativement le fonctionnement (on va commencer alors à parler d'intégration continue).

n'est-ce pas un métier du testeur?

Il y'a des gens qui ne font que écrire des tests , mais c'est assez rare. En général c'est le développeur lui même qui écrit ses tests.
JE suis pas adepte de la pratique , mais il me semble que dans un monde idéal on écrit ses test avant même d'écrire ses classes métier

[Lucas Panny]

Bref, le test-driven development consiste donc à imaginer ce que sera l'application php au niveau code source. Une technique pour éviter les régressions aussi?

En théorie, c'est assez clair mais en pratique???

A chaque classe va correspondre différents tests (en général un ou plusieurs test par méthode)

Comment? Le test unitaire consiste à essayer automatiquement des valeurs d'entrée à une fonction

[grunk]

Comment?

En général avecun framework dédié à cela et des assertion.

Dans ta classe de test tu vas appeler ta méthode à tester et vérifier via des assertion que sont retour est un entier par exemple.

Je t'invite à lire cet article sur phpunit (framewokr de test) ca devrait te permettre d'yvoir plus clair

[gwinyam]

Pour faire simple, le principe du test-driven development (tdd), c'est que pas une seule méthode ou classe ne doit être écrite sans que son test n'ait pas été écrit auparavant.
C'est un peu brutal comme façon de travailler, je ne suis pas adepte de cette façon de faire mais elle se défend.

Un autre framework de tests qui me semble intéressant est Atoum, je ne me suis pas penché dessus mais je connais son créateur et je lui fais confiance sur la qualité de son produit. Si tu passes sur son blog, tu entendras parler régulièrement de tests unitaires.

[Lucas Panny]

C'est compliqué!
Il y a un vrai débat aussi sur sa potentielle utilité! Coder en plus de ce que je suis entrain de coder, de plus du code pour du test seulement

Je vais lire ton lien grunk
Concernant Atoum, c'est quoi le blog en fait?

[gwinyam]

C'est mageekguy qui s'en occupe, ça se passe par là: http://blog.mageekbox.net/?category/Projets/atoum

Je crois qu'il faut le contacter pour participer au projet ou pour en avoir une version parce qu'il est encore en béta de mémoire. Il est vachement sympa et assez ouvert d'esprit, n'hésitez pas. Dites lui que vous venez de la part de MathRobin. metagoto, un rédacteur d'ici le connait bien aussi

[Lucas Panny]

ok gwinyam

J'ai aussi entendu parler de Selenium RC pour le test automatique! Est-ce que quelqu'un m'en dire sur une phrase car là encore les résultats de recherche ne m'aident pas beaucoup

[grunk]

C'est compliqué!
Il y a un vrai débat aussi sur sa potentielle utilité!

Y'a pas de débat sur l'utilité des tests unitaires. Il sont un plus indéniable pour la robustesse d'une application.
En revanche ce qui est discutable c'est l'intérêt réel par rapport au temps passé à écrire ces tests.
Sur de petits ou moyen projet je suis pas convaincu que le temps investi dans les tests soit réellement rentables.

J'ai aussi entendu parler de Selenium RC pour le test automatique!

Me semble que Selenium RC est orienté test d'interface (comprendre clic clic souris) alors que phpunit est lui orienté test de code

[gwinyam]

Il y a justement mageekguy qui a lancé un second débat: ok tester les méthodes publiques, c'est important, mais les privées, ça répond à la tambouille interne d'une classe, donc pas besoin de le tester. Enfin bon, allez sur son blog si vous voulez mieux voir son point de vue, je ne le partage pas complètement. Et j'en débats déjà avec lui sur son blog d'ailleurs.

[Phelim]

Effectivement, je pense qu'il y'a un débat sur le test driven development plus que sur les tests automatisés.
Un testeur ça coute cher, et ça ne teste que la surface d'une application. Un développeur qui fait du test à coup de debugger perds beaucoup de temps et surtout doit recommencer tout le temps à la moindre occasion.

Si tu lances ton application, tu rentres des données pour tester une fonction, tu fais du test.

Le point positif du test unitaire c'est que tu testes directement le point que tu veux vérifier et surtout, tu laisses l'ordinateur bosser.
Le point delicat c'est que ça impose de penser son code initial différemment.

Tester unitairement une méthode si elle crée ses propres objets durant son appel ou fait appel à des fichiers de configurations ou des variables globales directement ... est pratiquement impossible.

Apres, il reste d'autre forme de tests automatiques comme le test fonctionnel (ou de recettes).

Ces tests n'isolent pas la méthode à tester mais font appel à tous les éléments en dessous de la méthode. C'est utile pour vérifier que l'application a le comportement attendu dans tel situation.
Ca permet de tester une non régression à haut niveau mais n'aide pas à identifier le point où un problème apparait.

Si j'ai 2 conseils à te donner :
- les tests ne sont réellement exploitables que si tu as besoin d'un clic ou d'une instruction pour les exécuter tous, donc automatise au maximum (un fichier batch ou shell pour les lancer tous).
- Un bug apparait, conçois un test automatique qui le reproduit et ensuite corrige le. Je pense que tu economiseras beaucoup d'heure d'xdebug ou d' echos et de var_dump.

[impossiblium]

Effectivement, je pense qu'il y'a un débat sur le test driven development plus que sur les tests automatisés.
Un testeur ça coute cher, et ça ne teste que la surface d'une application. Un développeur qui fait du test à coup de debugger perds beaucoup de temps et surtout doit recommencer tout le temps à la moindre occasion.

Un développeur qui fait du test unitaire en TDD fait bien plus que du test.
Il écrit le cahier des charges ET fait du test ET de la conception ET de la documentation, puisque ce sont les tests qui définisse l'interface de l'objet testé, ses fonctionnalités, et servent de documentation.
Et l'utilisation d'un débugger est très loin d'être incompatible avec l'écriture de tests unitaires, bien au contraire.
Un test valide un résultat, il permet de détecter un problème, il ne permet pas de le corriger : à objectif différent, outil différent.

Si tu lances ton application, tu rentres des données pour tester une fonction, tu fais du test.

Dans le meilleur des cas, tu testes tout dans le cas ou tout va bien, si tu es exhaustif dans tes tests, ce qui est quasiment impossible même sur un petit projet, du fait de l'explosion combinatoire qui se produit lorsque le nombre de fonctionnalité augmente.
De plus, tu y passes un temps fou, car tu fais tout à la main.
Bref, dans ce cas, tu coûte effectivement cher à ton patron, parce que tu n'es pas productif et efficace, sans parler du fait que tu n'as absolument aucune garantie sur le fait que TOUT est testé.
Et quand je dis tout, je veux parler de ce qui se passe lorsque le système de fichier est plein, lorsque la base de données ne répond plus, lorsque le réseau tombe, etc.

Le point positif du test unitaire c'est que tu testes directement le point que tu veux vérifier et surtout, tu laisses l'ordinateur bosser.

Le point positif du test unitaire, c'est qu'il permet de rejouer les tests à volonté de manière automatique, rapide et exhaustive, tout en assurant une conception objet saine et solide et une documentation du code, surtout en TDD.

Le point delicat c'est que ça impose de penser son code initial différemment.

Je plussoie, dans le sens ou il oblige à faire une bonne conception objet, c'est à dire respectant la loi de Demeter, SOLID, le découplage, etc.

Tester unitairement une méthode si elle crée ses propres objets durant son appel ou fait appel à des fichiers de configurations ou des variables globales directement ... est pratiquement impossible.

Complètement faux, du fait que l'écriture de tests unitaires oblige à avoir une conception correcte qui est par nature testable.
C'est juste plus ou moins compliqué suivant le langage (dans le cas de PHP, le fait qu'il ne soit pas tout objet est par exemple un problème) et surtout suivant les outils de tests utilisés.

Apres, il reste d'autre forme de tests automatiques comme le test fonctionnel (ou de recettes).

Ces tests n'isolent pas la méthode à tester mais font appel à tous les éléments en dessous de la méthode. C'est utile pour vérifier que l'application a le comportement attendu dans tel situation.
Ca permet de tester une non régression à haut niveau mais n'aide pas à identifier le point où un problème apparait.

Je dirais plutôt qu'un test fonctionnel permet de vérifier qu'un ensemble d'objet travaille correctement ensemble, alors que le test unitaire se concentre sur une classe "seule au monde".

Et un test unitaire est forcément rentable, quelque soit la taille du projet, ne serait-ce que parce qu'il permet de détecter les régressions et d'augmenter de manière drastique la qualité du code et surtout d'avoir une énorme confiance dans sa fiabilité.

Bref, le jeu en vaut la chandelle, mais en tant que créateur d'Atoum, je ne suis peut être pas forcément objectif .