Les tests unitaires, ça faisait un bail que je me disais qu'il fallait sauter dedans (comme tellement de bonnes résolutions qu'on prend au nouvel an. J'ai été prévoyant cette fois-ci) ben voilà, depuis un temps, c'est fait. Et ça pourrit la vie.

Ou du moins, on n'arrive plus à simplement s'assoir devant un son éditeur et coder en toute liberté, sans se soucier. On se disait qu'on avait tout dans la tête, on se sentait libre, on faisait de la voltige.

Ben après avoir gouté aux tests unitaires, on n'arrive plus à produire une fonction en toute simplicité, sans ressentir le manque d'assurance que procurerait un bon petit test qui nous dit "t'inquiete".

J'y ai brièvement trempé mon orteil, en codant un (petit) truc en python le mois dernier, et depuis je n'arrive plus à rien, tous mes autres environnements doivent intégrer un framework de test Xunit, sinon je deviens parano. PhpUnit, Eunit, PyUnit, PerlUnit, ...

Alors oui, la qualité du travail est amélioré, on est plus zen, les tests forcent les bonnes pratiques (si quelque chose s'avère intestable, c'est qu'il est mal implémenté), mais quand même. J'aimais bien écrire mes petites fonctions en toute naïveté..

Et vous ? Quel à été l'impact du passage vers les tests unitaires, voir le TDD (test-driven-development) ? Quel autre évolution à eu un impact durable, immédiat sur votre façon de coder ?

j'avais lu un petit article sympa la dessus :
http://www.xorax.info/blog/#programmati ... aires.html

Je trouve l'article léger et la conclusion plutôt hasardeuse.

Mais alors, quand utiliser les tests unitaires ?!

A mon humble avis, jamais,

Jamais ?
Les tests servent énormément en cas de refactoring, d'optimisation. Et ils servent bien sûr à cibler les problèmes. Il y a des frameworks pour valoriser une base de données pour les tests, il y a les Mock objects. Donc les problèmes listés ne sont pas si complexes à contourner.

Dire que ça ne sert à rien et que c'est simplement long et coûteux, je trouve que c'est un peu limite. C'est sûr qu'il y a souvent un manque de budget. Et que c'est un vrai chantier sur un projet.

Mais alors ça:

De plus les tests utilisateurs sont suffisants et ne requièrent pas de compétences particulières, et surtout, sont beaucoup moins couteux que les tests unitaires.

Non, ils ne sont pas suffisant, ils ne couvrent pas forcément tous les cas, et sont plus "généraux" (vous testez tout un process, mais un test unitaire sert justement à cibler un problème).

Ne requièrent pas de compétences particulières ? Ben si, il faut connaître l'appli un peu quand même, ou les outils utilisés etc.

Moins coûteux ? Tu lances des tests unitaires toutes les heures si tu veux, automatiquement. Alors qu'un mec devant sont écran, il est pas là tout le temps, il peut se tromper etc.

Bref, je n'adhère pas du tout à cet article, je crois que cette personne a un peu survolé le sujet.

Sinon pour répondre aux premières questions, les tests et la QA en général sont essentiels, peuvent être intéressants, mais sont souvent vu comme une contrainte par les développeurs (chargés d'écrire les tests ou de corriger leur code si on détecte des problèmes lors des tests), et comme ce n'est pas directement productif tout le monde s'en fout, les décideurs en premier, puisque tout est dicté par les coûts et que la qualité immédiate du produit n'est pas un objectif prioritaire (parfois). C'est donc très déprimant.

Tout à fait d'accord avec Ouckileu, l'auteur de ce post montre finalement une connaissance très limitée des tests unitaires.. dire que les tests se limitent à comparer des valeurs statiques, c'est très réducteur.

De plus, les tests ne s'écrivent pas à posteriori, mais a priori (c'est ça, le TDD, on écrit le test, il rate, on résout, il réussit, on enlève toute redondance (refactoring), et on relance). Ca permet de bien réfléchir, à l'avance, des fonctionnalités et des valeurs d'entrée et de retour de la fonction ou de l'objet. Avant même de commencer à coder, on à déjà une bien meilleure idée de ce qu'on va écrire. Alors oui, on est déjà censés le faire (qui analyse à l'avance chaque fois chaque bout de code ?), mais le TDD pousse cette manière de faire. Au final, le code est de bien meilleure qualité.

De plus, les tests peuvent être lancés à chaque modification. Je doute qu'un test manuel puisse faire le tour de toute une application à chaque petite modification.

Je me souviens d'ailleurs du cycle de développement d'un jeu on-line massif, ou l'application était mise à jour de façon constante. Dés qu'un développeur soumettait une modification ou un ajout, tous les tests étaient lancés, et s'ils réussissaient l'environnement de production étais mis à jour. Sans sourciller. Plusieurs fois par jour.

Il tests, c'est un peu comme un moniteur Nagios pour surveiller ses serveurs. On pourrait très bien vérifier chaque serveur à la main, en s'y loggant, en vérifiant ses différentes applications. Mais rien ne garantit qu'il ne plante pas justement quand vous quittez votre session. La seule façon de savoir est d'y retourner. Tandis qu'avec un moniteur du type Nagios, à chaque instant on voit si on problème se produit ou pas. On à l'assurance constante que tout va bien: c'est zen.
Même chose avec les tests unitaires: Avant, après quelques modifications, on devait vérifier l'application, s'assurer de ne rien oublier, aucun scénario possible. Alors que si les tests réussissent, on peut avoir confiance: c'est zen.

Et entre écrire une fois un test de 2 lignes et vérifier à chaque fois l'appli dans un navigateur (avec des echos, des print_r, etc...) ...

Bonsoir,

J'ai utilisé les tests unitaires il y a très longtemps (au moins 4 ans) avec PHPUnit et je pense que je n'étais pas assez mature pour en comprendre l'intérêt, néanmoins ce sujet m'intéresse de nouveau, j'aimerais pouvoir me refonder une opinion neuve.
J'aimerais savoir quels sont les outils de tests unitaire que vous utilisés en PHP ? Et pourquoi ?

Par avance,
Merci

Salut !

en ce moment j'y réfléchis aussi et penses envisager un test dans les prochains mois avec e principe de fonctionnement de SimpleTest
Le principe est intéressant, tu monte ton cahier des charge en php, et ensuit tu codes ... au moins tu as résolus l'ensemble des bugs avant de commencer à coder .. intéressant quand tu est responsable technique du projet est que tu as une armée de chinois qui remplissent les scripts .. tu n'as pas à vérifier leur taf, si ça passe à la vérif, c'est qu'ils n'ont pas fait de conneries !..
intéressant aussi quand tu dois refondre le script ou y revenir dessus 2 ans après, tu visualises p-e mieux sont fonctionnement, et si les modifs que tu lui apportent font planter la vérif, c'est que tu as oublier de conserver le comportement initial ...
Cela dit, moi je code +/- seul sur les taches qu'il m'incombent, donc ça risque de me prendre 1.5 fois plus de temps pour arriver au même résultat !..

intéressant quand tu est responsable technique du projet est que tu as une armée de chinois qui remplissent les scripts .. tu n'as pas à vérifier leur taf, si ça passe à la vérif, c'est qu'ils n'ont pas fait de conneries !..
intéressant aussi quand tu dois refondre le script ou y revenir dessus 2 ans après, tu visualises p-e mieux sont fonctionnement, et si les modifs que tu lui apportent font planter la vérif, c'est que tu as oublier de conserver le comportement initial ...

Attention
Les tests ne garantissent pas que le code est de qualité, juste qu'il fonctionne.
Les tests permettent de s'assurer des non-regressions quand tu repasses dedans, mais quand le code est pourri, justement parce que fait pas des chinois et que tu n'as pas controlé la qualité du rendu, c'est au moins aussi dur de reprendre le code

Bref, en conclusion, les tests permettent de gagner du temps lors de reprise du code, en checkant correctement les non-regressions, mais n'est pas un gage de qualité du rendu.
Penser le contraire est une grosse erreur

Bonjour,

Merci de vos réponse, je vais regardé du côté de SimpleTEST, qui propose également un outils de Benchmark, pratique pour les concours, je vais regardé du côté d'Hoa, il me semble qu'il faisait des trucs pas mal.

Perso, je n'ai utilisé que PhpUnit jusque la. Il reprend le principe de Xunit, qu'on retrouve dans d'autres langues, donc après PyUnit je l'ai trouvé assez aisé.

Juste une remarque sur le temps que ça prend: on y perd peut-être un peu lors de la première écriture d'une fonction ou d'un objet. mais on y gagne honteusement quand il s'agit de modifier la fonction/objet: on la modifie, et on lance le test. Pas besoin d'aller charger le site et le tester sous diverses coutures, en perdant à chaque fois quelques minutes. Or dans un développement long, on fait beaucoup de changements, de refactoring. Et la, le gain de temps est impressionnant. Sans compter qu'on se débarrasse d'un certain stress: on sait que l'application fonctionne. On peut le prouver, après chaque modification.

Et donc quand on fait une dernière modif d'ultra-dernière minute avant une importante présentation, si les tests passent, on peut y aller tranquillement. Sinon, c'est le stress garanti.

Mais ce n'est pas non plus une solution miracle, il faut s'y investir. Perso, je m'essaye au TDD, et jusque la c'est pas mal du tout. En fin de compte, ce n'est qu'un outil de plus, qui fonctionne plutôt bien.

Les tests unitaires ne sont qu'un aspect de la vérification informatique, il y à aussi les tests d'intégration, d'acceptation, de système, etc...

Je me permet de déterrer ce topic car je rentres à fond justement dans les tests unitaires avec PHP Unit mais il y a un point qui reste très obscur pour moi : concrètement et simplement, quelle est la différence entre Stubs et Mocks ? dans quels cas on choisit l'un et dans quels cas on opte pour l'autre ?
N'ayant pas grand monde pour m'aider là ou je suis ça car je suis sensé mener les premières mises en places des TU dans l'équipe, je galère sur ce point particulier.
J'ai lu quelques articles très intéressants sur le sujet et notamment celui-ci :
- http://bruno-orsier.developpez.com/mock ... -stubs/#LV

Mais je n'arrive pas à ressortir une réponse simple de ce qui est écrit.

Merci d'avance pour vos réponses

On me dit dans mon oreillette (d'une source souhaitant garder l'anonymat ) :
http://hoa-project.net/Event/Forumphp12.html
http://keynote.hoa-project.net/ForumPHP12/.

Merci pour ta réponse, mais les liens sont bloqués par l'entreprise >_<. Je regarderai ça de chez moi ce soir

Merci pour ta réponse, mais les liens sont bloqués par l'entreprise >_<. Je regarderai ça de chez moi ce soir

Mauvaise entreprise, changer entreprise.

Merci pour ta réponse, mais les liens sont bloqués par l'entreprise >_<. Je regarderai ça de chez moi ce soir

Mauvaise entreprise, changer entreprise.

ça n'est pas trop de mon ressort, je suis en SS2I et donc prestataire dans l'entreprise ou je fais ma mission sur l'intégration continue et les TU ^^

Mauvaise entreprise, changer entreprise.

ça n'est pas trop de mon ressort, je suis en SS2I et donc prestataire dans l'entreprise ou je fais ma mission sur l'intégration continue et les TU ^^

Tu as le choix de ne pas être en SSII !
Enfin bon, ce n'est pas le sujet, on diverge !