Discussion :

[_skip]

Je suis passé par différents extrêmes durant ma carrière (je bosse actuellement moi aussi dans une start-up). Nous sommes depuis 4 ans sur le même projet, à empiler des codes et développer des fonctionnalités.

Nous avons commencé dans une optique très dogmatique, tests unitaires à outrance, tout devait absolument être abstrait et mockable et nous avons fini changer d'approche. A présent nous avons choisi de cesser de s'imposer du test unitaire, et de faire plus de tests d'intégration.

En gros, 80% de nos tests sont des tests d'intégration qui se passent sur les couches les plus hautes de nos applications. Nous avons différentes test suites qui chargent un script SQL dans la base de données avec des enregistrements intéressants et nous lançons une batterie de test.
Nous avons opté pour cette approche car fabriquer en java des collections entières de faux objets pour nos mocks était très fastidieux et vu le modèle de développement très évolutif que nous suivions, la maintenance des tests devenait trop lourde.
Là on se contente d'avoir un script SQL h2 (pour les tests en mémoire sans dépendances spécifiques sur le poste de dev) et un script Postgresql pour les tests en condition plus... réelles, tous sont commités et versionnés dans notre source control. On a estimé que ça nous coûtait moins cher de populer une base avec des cas intéressants que maintenir des tonnes de Mocks. Et ça permet aussi de tester nos évolutions de schéma ce qui n'est pas insignifiant. Au démarrage d'une suite de test (du simple Junit en fait), on refabrique la DB, on lance nos traitements et on laisse les tests modifier réellement la DB, qui est détruite à la fin. Certains pourraient penser que c'est lourd, mais en fait c'est très rapide.

Cela nous permet de tester nos applications avec de vrais interactions qui passent par toutes les couches (y compris les DAO et les transactions SQL) et par rapport à des tests qui se feraient uniquement en mémoire, cela nous a sauvé la mise plusieurs fois.

Donc voilà, je peux pas généraliser cela à tous les projets sur terre, mais sur une application très orientée DB qui change beaucoup, je pense que c'est 80% du bénéfice pour 20% du boulot. En tout cas on a un bon compromis avec cette approche, même si elle n'est pas très académique. Elle permet de tester des cas d'utilisation réels qui traversent toutes les couches, et elle impose assez peu de contraintes de maintenance. Je peux refactorer lourdement sous le capot sans avoir besoin de beaucoup changer les tests, justement parce qu'ils se focalisent sur les couches hautes.

[Logan Mauzaize]

...

Tu sembles penser que c'est une aberration mais je pense de la même manière. En fait, mes tests les plus unitaires sont principalement de haut niveau (ex: appeler le main). J'ai juste quelques tests pour des algos un peu tordu ou dont je veux être sûr avant d'aller plus loin qu'ils fonctionnent correctement. Typiquement tout ce qui est transformation de données (ex : parsing XML, génération XSL-FO, restructuration de données plates).

Cependant mêmes les plus techniques reposent en partie sur la BD. J'ai comme tu le dis une appli orientée BD, du coup mon code le plus critique sont les requêtes de recherche par exemple.

Concernant la notion de "base jetable", pour moi c'est la base des tests : isolation des données et indépendances. Là où je bossais avant, on avait toute une API en ANT pour déployer/configurer l'application, ré(-initialiser) la BD et plein d'autres trucs. Ca me manque beaucoup là où je travaille actuellement. Mais on avait pas la même taille d'équipe (~30 contre 7 au max) et encore moins une sous-équipe dédiée aux tests.

[rimram31]

Sur la BDD, on peut aussi étudier les possibilités de snapshot d'une BDD de production, malheureusement souvent lié a la volumétrie. Mais ça permet d'éviter les erreurs de débutant avec des problèmes non identifiés sur une base, un peu trop, "de test", quand elle est pas vide (vécu!), cas un peu tordus mais bien réels où tout se passe bien en conditions de test mais l'erreur survient avec des data opérationnelles.

Sans parler bien entendu des tests de charge qui n'ont de sens qu'avec une volumétrie de production.

Mais dans tous les cas ça vaut le coup d'investir un peu en scripts de backup/restore de database de production

[Luckyluke34]

...

...

Intéressant. Par curiosité, en combien de temps s'exécutent vos suites de tests ?

J'ai remarqué que les équipes qui ont une grosse base de tests unitaires fonctionnent plus en mode TDD où le feedback rapide est primordial, et celles ayant une majorité de tests hauts niveau ressentent le besoin de lancer leur suite de tests moins fréquemment.

Même si je suis plutôt dans la première catégorie, je confirme l'utilité des tests d'intégration et l'intérêt d'une BDD en mémoire pour tester la persistance.

[Logan Mauzaize]

Ca dépend des projets et du niveau du test "unitaire" ou de "validation".

Les tests unitaires pas plus de quelques minutes. Pour les tests de validation, ca prends environ une heure sur chaque projet (en dehors des tests de perf).

[_skip]

De mon côté, nous avons différentes suites selon les parties de l'applications visées, exécutées en mémoire depuis l'IDE, elles prennent moins d'une minute chacune.
On complète avec des tests de montées en charge qui sont effectués avec une BDD d'un client qu'on trouve particulièrement chargée et intéressante.

Pour le TDD, je dirai que c'est une approche qui a le mérite d'être structurante, mais je pense pas qu'elle ne convienne pour toutes les équipes ou toutes les façon de bosser. Nous mêmes faisons beaucoup d'essais à l'arrache et ne suivons que très rarement des specs, ça va parce qu'on est pas trop nombreux aussi. On implémente, on test, si c'est cool on refactore et on décide d'une interface, si c'est pas terrible on jette et on cherche comment faire autrement.
C'est vraiment du quick an dirty suivi de validation et de refactor. On ouvre une branche, on implémente en bourrin, puis on décide si on jette la branche ou si on fait joli puis on merge. Nos tests sont plus du blindage et de l'anti-régression qu'autre chose.
Difficile de justifier un travail conséquent d'écriture de test alors qu'on fait de l'expérimentation. Maintenant celui qui me dis que sur un projet avec beaucoup d'intervenants ça ne tient pas, je vais pas forcément le contredire.

C'est clair c'est pas ce que tout le monde fait, c'est pas ce que les bouquins et les consultants agiles disent de faire, mais le résultat est là et les délais sont à peu près tenus, alors... L'aspect primordial c'est qu'on remet souvent beaucoup de chose en question, et les tests unitaires ont plus de chance de se retrouver sur le chemin que des tests de hauts niveau.

[Luckyluke34]

Les tests unitaires pas plus de quelques minutes. Pour les tests de validation, ca prends environ une heure sur chaque projet (en dehors des tests de perf).

Du coup, lorsque tu commit du code, est-ce que tu as vraiment confiance dans le fait que tes tests "unitaires" (tu disais qu'ils étaient quand même de haut niveau) constituent un filet de sécurité assez complet ? Ou tu passes aussi les tests de validation à chaque commit ?

C'est clair c'est pas ce que tout le monde fait, c'est pas ce que les bouquins et les consultants agiles disent de faire, mais le résultat est là et les délais sont à peu près tenus, alors...

Pourtant Kent Beck, le papa de TDD, dit quelque chose qui n'est pas si éloigné : pour les PoC et autres prototypes, il ne fait pas de tests avant. Par contre une fois que les inconnues techniques ont été levées et qu'il a une idée générale de la façon dont les modules de code vont s'agencer, il se met en mode TDD pour instaurer un rythme de travail qui lui permet d'avancer par petits pas en toute confiance. Comme les boucles TDD sont très courtes, à un instant donné on est assuré d'avoir du code fonctionnel, propre et testé qui date de quelques minutes auparavant et de pouvoir revenir à cet état précédent à tout moment.

[Logan Mauzaize]

Du coup, lorsque tu commit du code, est-ce que tu as vraiment confiance dans le fait que tes tests "unitaires" (tu disais qu'ils étaient quand même de haut niveau) constituent un filet de sécurité assez complet ? Ou tu passes aussi les tests de validation à chaque commit ?

En fait une des appli est essentiellement Web et on a pas encore fait l'effort d'automatiser l'exécution des tests IHM et/ou JSF. Les tests JUnit touchent des parties très particulières de l'application (ex : parsing XML pour transformer des BLOBs en objet Java puis persister le résultat en BD) qui évoluent très peu, on les lance donc rarement.

Pour l'autre, on lance rarement les tests autos avant de commit. Souvent on peut vérifier le résultat très rapidement. Et pendant les développements, une partie partie des tests est souvent cassée car les données de référence ("expected") ne sont plus bonnes.

Autrement, mon avis de confiance est très bon concernant ce que vérifie le test et fonction de l'étendu des développements. Pour la non-régression, j'ai assez peu de code/architecture spaghetti donc quand je modifie quelque chose, j'ai une très bonne vision des cas possibles.

[_skip]

Pourtant Kent Beck, le papa de TDD, dit quelque chose qui n'est pas si éloigné : pour les PoC et autres prototypes, il ne fait pas de tests avant. Par contre une fois que les inconnues techniques ont été levées et qu'il a une idée générale de la façon dont les modules de code vont s'agencer, il se met en mode TDD pour instaurer un rythme de travail qui lui permet d'avancer par petits pas en toute confiance. Comme les boucles TDD sont très courtes, à un instant donné on est assuré d'avoir du code fonctionnel, propre et testé qui date de quelques minutes auparavant et de pouvoir revenir à cet état précédent à tout moment.

Ben cela fait plaisir de savoir que l'auteur de la méthode n'est pas lui-même un bon gros intégriste comme il y en a 100 fois trop dans ce milieu .
Est-ce que tu appliques les préceptes du TDD à la lettre? Enfin principalement l'écriture de test AVANT le code ?

[rimram31]

...Pour l'autre, on lance rarement les tests autos avant de commit. Souvent on peut vérifier le résultat très rapidement...

Ca va dépendre de l'environnement ... Dans ma carrière j'ai vu tout et n'importe quoi, des développeurs "consciencieux" (pour moi tout simplement normaux!) qui vérifient au cours du dév que le code écrit fait bien ce qu'ils pensent qu'il doit faire et, a l'autre bout, j'ai connu des dev livrant du code 'premier jet" écrit sur la seule base d'une spec par exemple sans absolument aucun test et tout surpris ensuite que leur "programme" ne faisait même pas ce qu'ils pensaient qu'il devait faire réduisant leurs "tests" a la capacité de leur outil (IDE, compilo ...) a "avaler" les lignes de code écrites.

Donc si tu as un environnement peu stable (jeunes développeurs, turn over consultants ...), catastrophe inévitable sans tests rigoureux, au contraire si tu bosses avec une petite équipe très impliquée, le code livré est déjà très proche du résultat final.

Comme j'ai toujours eu l'habitude de coder par "petits bouts", validés unitairement, pour assembler ensuite, avec ma propre mixture d'approche bottom-up/top-down selon la situation, je n'ai jamais vraiment compris l'excitation de l'époque sur la "révolution" des tests unitaires (si ce n'est une assistance pour les implémenter). J'ai toujours mes "print" un peu partout dans le code

[Luckyluke34]

Est-ce que tu appliques les préceptes du TDD à la lettre? Enfin principalement l'écriture de test AVANT le code ?

Oui, j'aime cette façon de travailler car ça m'aide à penser le "pourquoi" avant de coder le "comment". Le test étant le premier client du code (alors même que ce dernier n'existe pas encore), ça me permet d'aborder la conception du point de vue du consommateur et de développer le strict minimum dont il a besoin. En quelque sorte, "l'utilisation crée l'organe", et non pas "un plan théorique défini à l'avance et/ou des suppositions créent l'organe". Il y a aussi la satisfaction associée à chaque barre verte qui instaure un rythme de travail que je trouve plaisant et plus confortable que se lancer dans des gros dev sans filet en priant pour retomber sur nos pattes à la fin (sachant que plus le dev est long, plus il y a de chances pour qu'on oublie ce que "retomber sur nos pattes" voulait dire à l'origine).

Par contre il y a des cas où je ne fais souvent pas de TDD voir pas de tests du tout : pur UI (même si c'est mal), prototypes/PoCs, etc.

[Logan Mauzaize]

Ca va dépendre de l'environnement ... Dans ma carrière j'ai vu tout et n'importe quoi, des développeurs "consciencieux" (pour moi tout simplement normaux!) qui vérifient au cours du dév que le code écrit fait bien ce qu'ils pensent qu'il doit faire et, a l'autre bout, j'ai connu des dev livrant du code 'premier jet" écrit sur la seule base d'une spec par exemple sans absolument aucun test et tout surpris ensuite que leur "programme" ne faisait même pas ce qu'ils pensaient qu'il devait faire réduisant leurs "tests" a la capacité de leur outil (IDE, compilo ...) a "avaler" les lignes de code écrites.

Donc si tu as un environnement peu stable (jeunes développeurs, turn over consultants ...), catastrophe inévitable sans tests rigoureux, au contraire si tu bosses avec une petite équipe très impliquée, le code livré est déjà très proche du résultat final.

Comme j'ai toujours eu l'habitude de coder par "petits bouts", validés unitairement, pour assembler ensuite, avec ma propre mixture d'approche bottom-up/top-down selon la situation, je n'ai jamais vraiment compris l'excitation de l'époque sur la "révolution" des tests unitaires (si ce n'est une assistance pour les implémenter). J'ai toujours mes "print" un peu partout dans le code

Comitter un truc qui ne fonctionne qu'à moitié ne me choque pas si c'est pour sauvegarder du travail et que ca n'impacte pas les autres. Le truc c'est que dans ce cas, j'impose l'utilisation des TODO pour ne pas oublier les explications sur le RAF et la localisation dans le code.
J'ai travaillé sur des projets avec un important turn-over et même sans être rigoureux on s'en sort. Le problème est plus souvent dans l'architecture spaghetti. Tu modifies d'un côté et ca pète complétement à l'opposé. Sans relancer la batterie de test ca reste invisible. L'effet pervers en plus c'est que le gars qui va bosser sur la fonctionnalité où ca a pété, va penser que c'est de sa faute et perdre du temps à débugger.

Une solution à ce problème c'est de travailler par branches (isoler les développements), passer la batterie de tests une fois les devs terminés et merger ensuite. Cependant, si les développements sont "petits", ca va prendre beaucoup de temps.
Le mieux c'est encore de découper en tâches les plus unitaires possibles.

L'avantage d'un test unitaire, c'est que c'est une vérification automatique et reproductible. Et une fois passer quelques infos sur une API custom (déploiement, vérification, etc.), c'est très rapide à écrire.

Par contre il y a des cas où je ne fais souvent pas de TDD voir pas de tests du tout : pur UI (même si c'est mal), prototypes/PoCs, etc.

C'est marrant ce sont surtout les PoCs que je teste unitairement car je connais le but à atteindre et donc les vérifications à faire. J'entre un peu dans un mode "Behavior Driven Development".