Discussion :

[Marco46]

@Luckyluke34 : tu ne fais pas du test fonctionnel pour dire que ton logiciel est fiable. Tu fais des tests au dessus, à savoir des tests de performance.
Ce n'est pas parce qu'une fois ton test passe OK qu'il passera OK la seconde fois (bon sauf dans des cas vraiment spéciaux où l'environnement extérieur n'a aucune incidence sur la fonctionnalité, du genre tu rentres 1 et 1 dans un calculette et elle te sort tout le temps 2). Et ça c'est pas les TU qui vont t'apporter quoi que ce soit.
J'ai au contraire des exemples au boulot sur d'autres projets où ils avaient dans leurs tests 80% de TU. Bah bizarrement tous leurs TUs sont au vert mais leur système ne tient pas 100 itérations d'une fonctionnalité.
Le TU ne va pas te mettre en évidence une fuite mémoire par exemple. Bref n'osez pas me parler de fiabilité de votre logiciel après avoir passé des TUs cela ferrai virer au fou rire n'importe quel expert...

J'avais zappé ça.

En fait, tu ne sais pas du tout ce qu'est un test unitaire et à quoi ça sert. C'est difficile de discuter dans ces conditons. Un TU n'est pas un benchmark, un TU ne sert pas à détecter la fiabilité d'une application (qui est un ensemble d'objets) puisqu'il ne test qu'un tout petit morceau (le plus atomique possible), le TU ne sert pas du tout à mettre en évidence une fuite mémoire. Il sert à détecter les inévitables régressions.

[Luckyluke34]

Mal m'en prenne... Si elles avaient été mise en static c'était pour une très bonne raison (qui aurait du être commenté faut l'avouer). => dépassement de pile

Qui aurait du être commenté, ou... testé. Il suffisait à ton prédecessur d'écrire un petit test vérifiant qu'il n'y a pas de dépassement de pile. Ce dernier aurait échoué dès que tu as fait la modif. Rien qu'en regardant le nom du test qui échoue, tu aurais vu d'où venait le problème et remis le static...

Quand on reprend du code complexe, c'est humain de le considérer comme un mikado magique à ne toucher sous aucun prétexte. Le problème, c'est qu'on crée ainsi un socle rigide, inévolutif et impénétrable sur lequel se baseront tous les développements futurs. Cela aboutit à des aberrations, plein de bouts de code "WTF" encore plus difficiles à comprendre, sans compter les solutions de contournement bizarroïdes s'il y avait des bugs à l'origine. Couche après couche, l'application va pourrir lentement.

Il faut avoir le courage de modifier le code legacy. Pour cela, on doit avoir 1/ une bonne compréhension de celui-ci (ce qui veut dire démystifier sa magie) et 2/ un filet de sécurité qui nous garantit qu'on ne casse rien. Les tests (unitaires ou pas) sont un des moyens d'y parvenir.

[Marco46]

2/ un filet de sécurité qui nous garantit qu'on ne casse rien. Les tests (unitaires ou pas) sont un des moyens d'y parvenir.

C'est pas que ça garantit de rien casser c'est que ça permet de voir qu'on casse.

[souviron34]

Le TDD est mort ? Non, pas vraiment, peut-être que oui [/SIZE]
[SIZE="1"]La communauté agile taraudée par un débat autour du TDD

• ...
• Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.

....
Et vous ?

Que pensez-vous du TDD ?

Pensez-vous que le TDD est un concept révolu ?

Je vous renverrais à mon post ici dans la discussion d'à côté..

et j'insisterai sur le point cité plus haut dans le PO :

Enfin, un autre intervenant, Gil Zilberfeld, cite un passage du manifeste agile : « nous découvrons de meilleures façons de développer des logiciels en les faisant et en aidant les autres à le faire . Un passage lourd de sens, comme pour dire que le TDD n’est qu’un outil et une manière de faire parmi tant d’autres après tout.

C'est une des choses qui m'énervent profondément, cette manie de tout vouloir déifier et utiliser de manière mono-théiste quand quelqu'un propose quelque chose...

Je vais me répéter, mais l'agilité est un état d'esprit, pas l'application d'un outil, ou d'une méthodologie..

Confondre l'outil et le but est absurde...

[Luckyluke34]

C'est pas que ça garantit de rien casser c'est que ça permet de voir qu'on casse.

Oui, mais quand tu vois que ça a cassé sur ta machine ou en intégration continue, tu ne déploies pas en prod, donc tu ne casses rien

[Logan Mauzaize]

C'est comment avoir un projet mort-né...
Le test unitaire n'est pas représentatif d'un logiciel, il n'est représentatif que d'une fonction dans le code (et je fais bien le distingo entre fonction du code et fonctionnalité du système !).

Je crois que tu n'as pas une bonne connaissance du TDD. Dans les grandes idées, le but c'est d'écrire l'utilisation du code, puis l'implémentation. Puis de refactorer, au fur et à mesure, pour (ré-)assembler le système. C'est une approche bottom-up contrairement à la plupart des pratiques.
De cette pratique a également émerger le BDD, qui va plus loin, en écrivant d'abord des tests sous la forme d'interaction entre l'utilisateur et le système.

Rails, au contraire, affiche une pratique opposé en te proposant une architecture template grâce au principe de scaffolding que tu viens ensuite remplir avec du code spécifique. Le but étant d'avoir une architecture "saine" et "standard". Tu retrouves ce principe également dans Spring ROO ou Play.
Je trouve que ce genre d'approche rejoint fortement le MDA et j'aurais tendance à préférer cette dernière approche si je dois concevoir un système. Le scaffolding devrait être réservé aux développements rapides (besoins spécifiques faibles, prototypage, démos, etc.) ; néanmoins ce sera à la condition de bien maîtriser l'outil sinon rien ne sera rapide. De plus, ces outils de RAD ont fortement tendance à te lier à l'outil (éditeur, framework, etc.)

En résumé, MDA ou scaffolding sont de bons outils qu'on devrait tous avoir mais qui nécessitent de bien connaître leur écosystème au risque de se sentir pris au piège alors que le TDD n'est qu'une approche de la façon d'appréhender le code. Celui-ci nécessitera donc moins d'expérience pour en profiter pleinement.

• oui pour le test en général
• non pour le micro-test systématique
• non pour l'obligation stricte d'écrire les tests avant

Autant être précis ;-)

Après qu'on veuille imposer à un débutant qu'il écrive les tests avant pour le forcer à mener la réflexion sur l'architecture passe encore. Mais l'imposer à un professionnel chevronné, c'est encore du dogmatisme. Il faudrait qu'on commence à comprendre que dans ce métier, il y a pas de standards qui tiennent. On résout des problèmes en prenant des aides partout où on en trouve, que ce soit des outils, des méthodologies, des techniques ou des idées.

Je pense pas que leurs auteurs est voulu dogmatisé leurs pratiques. Je pense surtout qu'ils ont voulu présenter l'essence de leurs méthodes (approches) du travail. Pour en faire un "papier" (livre, article, speak, etc.), il a fallu l'épurer pour que les gens en comprennent pleinement le sens (dans ses deux définitions : la signification et la direction).
Car, il y a des gens très doués et expérimentés dans le codage mais beaucoup moins pour la méthode et la qualité ; voir même très moyen sur les deux aspects. Et je pense que pour ces profiles, il est fortement recommandé de ne pas trop mixer diverses méthodes sous peine de faire une soupe infâme qui sera pire que l'auto-organisation anarchique qu'ils auront pu mettre en place.

Si vous devez avoir vos tests unitaires avant de coder quoi que ce soit c'est que vous avez fait toute la conception jusqu'au niveau le plus bas. Vous avez pensez à la moindre classe, la moindre fonction, le moindre opérateur... C'est une folie !
C'est complètement anti-agile c'est du cycle en V... (et encore, jamais vu de cycle en V aussi poussé...)

C'est justement agile et l'anti-thèse du cycle en V. En premier lieu, je remplis un objectif précis et (dé-)montrable, je fais aviser, ensuite j'arrange et enfin je suis prêt à poursuivre.

Il me semble qu'il fait une petite confusion, non? Par définition les tests unitaires ne sont pas fait pour s'appliquer au niveau application/système mais au niveau le plus bas. Contrairement aux tests d'intégration qui eux ne devraient d'ailleurs pas être fait par les développeurs.

Les tests unitaires peuvent éventuellement être au niveau micro-systèmes. Et puis tout dépend de la vision (scope) de ton système.
Par exemple, en ce moment, je travaille sur un "quartier" du SI de mon client. Ce quartier se compose de quatre-cinq applications, chacune ayant différentes composantes en plusieurs couches. Je peux considérer le SI, le quartier, une application, un composant ou une couche comme "niveau application/système" ;-)
Mais dans la citation je ne vois nulle part où il est mentionné qu'il effectue des "tests unitaires[...] appliquer au niveau application/système", bien au contraire il précise "ils [les test unitaires] font oublier généralement les tests systèmes"

Par ailleurs je ne suis pas d'accord avec lui quand il dit que le développement logiciel n'est pas une science. D'une part je ne vois pas la contradiction: la science c'est de la créativité, certain diront même qu'il y a de l'art dans la science. D'autre part la question est de savoir ce qu'on fait de cette créativité? Si on la laisse à l'état brut, on fait n'importe quoi. C'est ce que fait un mauvais développeur. Si on s'en sert comme un point de départ, en organisant les choses de façon rationnelle, en faisant l'effort de comprendre le problème et en étant capable de justifier ce qu'on fait, c'est de la science. Il me semble que c'est ce que fait un bon développeur.

Je pense tout simplement qu'il est partisan du mouvement "Software craftmanship". L'artisanat étant souvent une alternative aux sciences (trop théorique) et à l'industrie (trop rationnelle).

Là où je le rejoindrais peut-être (je ne suis pas certain d'avoir compris le fond de sa pensée) c'est que se fier uniquement aux tests serait une erreur. Sans faire mon serment habituel sur les méthodes formelles, il est tout simplement impossible de tester entièrement une fonction. Ne serait-ce qu'un additionneur 64bits sur nos processeurs actuels. Ça nous fait 2*2^64 cas de tests. Rien que le temps de les réaliser sur un processeur 2Ghz par exemple (disons 2^21 Hz pour simplifier), ça nous fait 2^44 secondes, soit plus de 557 millénaires pour une fonctionnalité aussi simple, et encore il reste à faire la vérification du résultat sur chaque cas de test...

Heureusement qu'il n'est pas nécessaire de faire des tests exhaustifs pour faire une preuve, sinon on en serait encore à démontrer l'addition (pour rappel, l'ensemble des entiers naturels étant infinis ...). D'un point de vue purement code, il suffit de couvrir les branches (l'exhaustivité pourra être requise dans ce cas en incluant les branches des sous-modules).
Les méthodes formelles reposent sur le principe de "preuve mathématique" qui repose (en grande partie ?) sur la logique des prédicats : l'implication, sa transitivité et la contraposition (preuve par l'absurde).

Bref, le test est très utile mais il ne doit pas empêcher de rester intelligent, en particulier dans la façon de faire les tests, sinon on va facilement dans le mûr.

Je plussoie, même si je me demande pourquoi le "en particulier" ;-)

Alors, moi, personnellement, je n'utilise aucune méthode particulière et je m'en porte formidablement bien dans ma tête...
Je n'ai pas un process à respecter à la lettre... et comme je déteste que l'on m'impose quelque chose, je fais à ma sauce des logiciels dont mes clients sont forts content...

En ces deux lignes, tu présentes bien que tu n'es pas concerné par le sujet. J'estime que ces recettes qu'on nous vend partout sont à destination des décideurs (au sens de proposition comme dans un monde agile et non nécessairement dirigeant comme dans un monde hiérarchique) qui sont "victimes" de leurs projets.
Le problème étant que généralement tout n'est pas rose et il faut faire avec ses impératifs (normes, specs volatiles, collègue fainéant/distrait, etc.). Et c'est dans ces moment-là qu'il est nécessaire de s’asseoir cinq minutes, d'arrêter de construire des rails qui vont droit dans le canyon (variante du "nez dans le guidon") et de bien réfléchir à la façon de travailler (organisation, méthode, process, etc.).

Une requête SQL (SELECT) ça renvoie soit un objet (un ensemble de rubriques), soit une collection d'objet. Ce n'est pas compliqué de mocker la fonction qui te renvoie ça.

Oui mais tu ne tests plus la requête ... Je vais te donner un exemple tout con, je bosse avec une base DB2, H2 et Oracle. Sauf qu'en DB2, je peux trimmer les chaînes, et l'égalité fonctionne ('FOOBAR' = 'FOOBAR '). Donc si je conserve ou pas les espaces, ca fonctionnera plus sur une autre BDD. Le test d'intégration a donc plus de valeur que le test unitaire.

Ca coute plus cher à l'instant T, pas sur l'ensemble du cout du projet.

C'est anti-agile comme raisonnement, tu ne peux pas raisonner sur une finalité, puisque tu ne sais pas quand elle interviendra.

Quand je dis 100% de couverture de code, c'est 100% de couverture sur son propre code, il ne s'agit pas de tester que le JDK fonctionne ou qu'une dépendance externe fonctionne normalement :/

100% de couverture du code n'indique pas 100% de couverture des branches d'une méthode, ou plus complexe, d'un arbre d'exécution. D'ailleurs statistiquement ce sera surement impossible à atteindre, une pré-condition finira par empêcher l'exécution de certains cas plus bas dans tes couches.

Ce n'est pas une pique arrogante, je veux juste mettre en évidence que sans tests et sans couvrir la plus grande portion de code possible tu es en mode petit bonheur la chance. Tu le dis toi même quelques lignes au dessus : "Pour moi le test c'est comme une assurance, il y a ce que ça coûte, et ce que ça couvre. . Si tu veux la couverture de risque la plus élevée [...]"

Premièrement, je pense que viser la couverture de code plutôt que la complexité est une aberration. Qui tend à faire passer une idée à un dogmatisme puis à un fanatisme.
Ensuite, le risque 0 n'existe pas. Et le 100% risque non plus, sinon on ne le ferait pas. Et entre, il existe une très grande variabilité que chacun devra mesurer, puis prendre en considération. C'est d'ailleurs tout le boulot de la gestion de projet (et d'entreprise !)

Je ne suis pas du tout d'accord c'est sur le cout. Sur l'ensemble du projet ça ne coute pas plus cher c'est faux faux faux archi faux.
En quoi est-ce arrogant de dire ça ?

Parce que tu supposes tout connaître tout de tout, ce n'est pas le comble de l'arrogance ?
Le test a le même coût que la qualité, que l'on pourrait mettre dans le même panier. Tu cherches à prévenir de potentiels coûts futurs, sauf que ceux-ci ne se présenteront peut-être pas.
Affirmer que l'assurance (qualité ou non) n'a pas de coût c'est simplement dire que les délais et les budgets tendent vers l'infini. Certains projets vivent très longtemps et d'autres sont au contraire très courts.

A te lire on dirait qu'écrire les TU c'est plus long que d'écrire l'application en elle-même.

Oui sans équivoque, je dirais que pour une application bien testé, il y a 2-3 lignes de test pour 1 ligne de code. Donc à moins d'être 2-3x plus productif en test qu'en réalisation, c'est plus long d'écrire les TU que l'application.

Et ce surcout tu le récupères largement sur la maintenance (qui est ce qui coute le plus cher dans un projet pour rappel)

Si maintenance il y a ... 100% de couverture par les TUs ne veut pas dire 0% de bugs. Il faut donc que ton taux d'éviction des bugs par les TU soit supérieur au cout de la correction de l'ensemble des bugs à venir ... Et dans tout ce surcoût, tu as 0% de couverture en intégration à moyen, petite et grande échelle (voir plus haut mon exemple d'échelle).
Et rien n'empêche d'atteindre une très bonne couverture avec les TI.

Je pense exactement l'inverse, plus le projet est petit, plus tu peux te passer des tests unitaires. Mais plus le projet est gros, plus le temps de build est long, et plus il faut y aller avec parcimonie avec les tests d'intégration et e2e et donc plus les TU sont pertinents.
Un build qui dépasse 5 mins c'est un build trop long. L'avantage des tests unitaires c'est que tu peux tout couvrir (quelque soit la taille du projet) tout en conservant un temps de build raisonnable. Et ça sera 100fois plus facile à maintenir que des tests d'intégrations qui vont mettre en oeuvre 3 ou 4 couches/composants (db, webservices, interface, ...)

Deux choses :

1. Plus le build est long, plus je veux rentabiliser son temps. Donc plutôt que d'exécuter 1000 TU de 1s, je préfère lancer 100TI de 5s. Et avec un bon filtrage par module (en fonction des impacts), je pourrais me contenter d'en lancer qu'une sélection. Filter les TUs c'est souvent compliqué car il faut analyser les dépendances entre packages alors que les dépendances modulaires sont déclaratives la plupart du temps.
2. Plus le build est complexe, plus je veux vérifier les problèmes d'intégration plutôt qu'unitaire (qui est le cadet de mes soucis), je fais confiance à chaque équipe pour me produire un produit de qualité "suffisant".

A quoi fais-tu référence quand tu pas de "e2e" ?

Par ailleurs, plus le projet est gros, plus il y a de chances d'avoir des régressions, plus il y a de bugs, etc ... Donc il ya un intérêt accru à avoir des TU pour compenser l'instabilité du à la taille.

Une petite question pour fixer une aile d'avion, tu aurais tendance à utiliser 1000 vis ou 100 rivets ?
Et pour fixer une étagère, 10 vis ou 1 rivet ?

Il ne s'agit pas de livrer sans bugs (même si mécaniquement tu en as beaucoup moins), il s'agit d'avoir de la visibilité avant de déployer et de se consolider sur le long terme.

Aucun chance d'éliminer tous les bugs "unitaires" et toutes les chances de passer à côté des bugs d'intégrations ... Le bon moyen de rien voir venir avant le long terme !

Avec un build de quelques minutes et de bons TU tu livres une version quand tu en as envie. Tu peux livrer plusieurs fois par jour, petit morceau par petit morceau, c'est 100 fois mieux qu'une grosse version tous les 3 mois à l'ancienne.

Le rapport de temps entre TU/TI/TV n'étant pas de cet ordre de grandeur, je peux quand même livrer dans la journée un truc "propre" plutôt que 10 trucs crades dans la journée.
Exemples ou ce n'est pas applicable :

• Certaines organisations imposent un délai minimale entre la commande et la mise en production. Pour justement assurer la maturité du produit.
• Certains processus de livraison/mise en production nécessitent des intervenants externes qui facturent éventuellement à l'intervention (sans parler de planification). Il faut donc minimaliser la quantité (et en profiter pour améliorer la qualité).
• Certaines applications sont soumis à un SLA qui réduit grandement le temps et le nombre d'intervention.

Oui, surtout que par principe un test unitaire est 100% automatique, il y a juste les cas de tests à lister, on complète éventuellement lors de la découverte d'un bug. On le fait une fois pour toute et d'une version à l'autre il y a juste à "appuyer sur le bouton"

Pour exécuter les tests oui tu "appuies sur un bouton", mais ensuite il faut réagir aux échecs. Et c'est là que commence le debuggage.

Mise en situation:

Tu entre dans une nouvelle équipe un nouveau projet, le projet a une business logic extrêmement complexe et des fichiers de 2000 lignes avec des appels de fonction à ne plus finir.
Tu recois ta première story, tu as absolument aucune idée de comment faire, ni de par oû commencer. Alors tu commence à lire le code pour essayer de comprendre. Puis à un certain point tu PENSE avoir trouvé une piste pour atteindre ton objectif.

Alors quest-ce que tu fais ? Tu te lance dans l'ecriture de tests ? Sa semble risqué non ? Tu n'as aucune idée si la piste que tu as trouvé te permet vraiment d'accomplir ton objectif.
Alors pourquoi commencer à "mocker" une tonne d'objets pour ecrire tes tests et passé possiblement quelque heures sur quelque choses qui ne fonctionneras peut être pas.

Pour ma part, je commence par trouver le chemin le plus court pour atteindre mon objectif en testant different appel de fonction et en ecrivant par exemple une petite fonction anodine pour passer du point A à B.
Quand jai terminé, je suis en mesure de mieux comprendre la story dans son ensemble et de penser à comment je vais réaliser le travail proprement. Par la suite je commence l'ecriture des tests.

Tu es comme notre auteur, tu n'as pas assimilé TDD. Dans ton exemple, tu expérimenteras à travers un test avant de refactorer et de créer des méthode(s)/classe(s) pour gérer ton cas. Ainsi tu pourras commencer à faire quelques expérimentations avant d'avoir écrit la moindre classe. Et peut-être d'ailleurs qu'au final tu ne créeras ni méthode, ni classe ; tellement le code est trivial et isolé.

Que pensez-vous du TDD ?
Pensez-vous que le TDD est un concept révolu ?

Je pense que TDD émet beaucoup de bons principes qui comme on le dit souvent à propos du livre "Coder proprement" : je le savais mais je le faisais pas.
Gardons les idées et faisons le tri en fonction des contextes. L'auteur de la méthode en fera autant que vous ;-)

Pour ma part je pense que les tests sont importants et devraient être automatisés autant que possible. En soit, je fais rarement du test "unitaire". Je préfère toujours travaillé avec un mini-système car il est rare que mes méthodes/classes fassent des choses trop complexes.
Par contre si cela arrive alors, j'y vais franco. D'ailleurs j'ai découvert il n'y a pas très longtemps l'excellent "EclEmma" qui donne la métrique la plus importante à mes yeux "missed instructions". Ce qui permet rapidement de voir les choses (potentiellement) complexes qu'on aurait oublié (ou d'on ne s'est pas rendu compte).

[Gruik]

Que pensez-vous du TDD ?

Je vais m'exprimer sur la philosophie générale qui consiste à écrire des tests automatisés (en amont ou pas) mais du coup je sais pas si c'est HS (si TDD est une méthode qui définit plus de choses).

Je pense qu'on devrait chercher à automatiser au maximum un ensemble de tests, maintenant c'est pas forcement possible suivant le contexte et l'entreprise.
Pour la nature et la quantité des tests, il y a débat visiblement.

Pour moi le test de l'ensemble des fonctionnalités du système devrait être automatisé de manière exhaustive (donc un maximum de cas, en prenant en compte des scénarios peu communs et d'erreur), afin d'avoir la doc exhaustive des fonctionnalités et cas gérés par le système (en remplacement d'une éventuelle doc donc).

Pour leur nature (TU ou autre), dans le cas d'un projet sur mesure pour un client, comme ça a été dit par skip, je préfère des tests macroscopiques qui simulent l'action d'un utilisateur (vous appelez ça TI, soit) et mettent en oeuvre toute la chaîne logicielle comme en prod, car le résultat du test pourrait montrer des problèmes très variés, et cela teste également les classes sous-jacentes dans leur contexte d'utilisation principal. Au final, il n'y a nécessité de faire des TU sur ces classes sous-jacentes (typiquement les classes métier) que si on les voit comme des composants réutilisables dans d'autres contextes (ce qui devrait être le cas d'un point de vue objet mais en pratique il y a souvent un couplage d'une façon ou d'une autre à leur contexte d'utilisation principal).
On utiliserait les TU plutôt dans le cas d'un projet de type "bibliothèque", ou l'API est clairement définie, et les tests unitaires corroborent la doc.

Il faut noter une difficulté à décider de l'ensemble des tests, des fois c'est trop, des fois pas assez. Ça nécessite d'imaginer les éventuels problèmes avec une implémentation donnée (ou l'implémentation en cours ? c'est peut être un piège de croire ça.) Exemple, on sait que l'addition 2+2 fonctionne, on va pas tester 2+3, mais on peut considérer (car on a une idée de l'implémentation possible) que 2+0 pourrait provoquer des choses bizarres alors on le teste.

Il faut noter aussi que faire des TU sereinement dans son projet, de la façon soutenue par Marco46, n'est possible que si on maîtrise le framework sous-jacent si il y en a un (c a d, il vaut mieux qu'il soit maison). J'ai essentiellement bossé sur de la modification de logiciel open source, et du coup je ne pouvais pas me permettre de modifier le framework du soft de base pour faire en sorte qu'un mocking complet puisse être possible.
Autre problème avec la modification de logiciel open source, c'est qu'on a du mal à décider de la couverture de ses tests : il faudrait potentiellement écrire des tests pour les fonctionnalités du soft de base mais ce serait la folie ; ou sinon se poser avec le client et identifier point par point les fonctionnalités du soft de base qui vont être utiles, afin de réduire le nombre de tests.

Pensez-vous que le TDD est un concept révolu ?

Si on parle de la philosophie générale de TDD, j'espère pas, car sinon ça veut dire que la qualité est un concept révolu.

[transgohan]

Je crois que tu n'as pas une bonne connaissance du TDD.

Je parlais dans cette citation uniquement des TUs.
Il était mis en avant que le TDD était assuré par les TUs ce qui est une aberration puisque le TDD ne se limite pas qu'à cela.

[Marco46]

Oui mais tu ne tests plus la requête ... Je vais te donner un exemple tout con, je bosse avec une base DB2, H2 et Oracle. Sauf qu'en DB2, je peux trimmer les chaînes, et l'égalité fonctionne ('FOOBAR' = 'FOOBAR '). Donc si je conserve ou pas les espaces, ca fonctionnera plus sur une autre BDD. Le test d'intégration a donc plus de valeur que le test unitaire.

Oui tu ne testes pas la db via le TU (c'est le boulot des TI on est d'accord), tu testes la logique que tu peux avoir après la réponse de la db. Donc quand ta db te retourne un résultat ou une exception. Pour faire cela en TU il est bien nécessaire de mocker la DAO.

C'est anti-agile comme raisonnement, tu ne peux pas raisonner sur une finalité, puisque tu ne sais pas quand elle interviendra.

Je parle de réalité comptable concrète pour le coup. Un projet a un début et une fin. Quand la fin arrive on fait le bilan et on voit ce que ça a couté. Tu peux donc savoir le poids de la maintenance dans un projet et prendre des mesures pour réduire ce poids. Augmenter la couverture de test fait parti des solutions.

100% de couverture du code n'indique pas 100% de couverture des branches d'une méthode, ou plus complexe, d'un arbre d'exécution. D'ailleurs statistiquement ce sera surement impossible à atteindre, une pré-condition finira par empêcher l'exécution de certains cas plus bas dans tes couches.

On est d'accord, je n'ai peut être pas assez détaillé ma réponse ça me semblait assez évident.

Premièrement, je pense que viser la couverture de code plutôt que la complexité est une aberration. Qui tend à faire passer une idée à un dogmatisme puis à un fanatisme.
Ensuite, le risque 0 n'existe pas. Et le 100% risque non plus, sinon on ne le ferait pas. Et entre, il existe une très grande variabilité que chacun devra mesurer, puis prendre en considération. C'est d'ailleurs tout le boulot de la gestion de projet (et d'entreprise !)

Il est évident que quand je dis couverture de code maximale, cela inclut la complexité, un test qui contient une assertion true === true ne sert à rien

Parce que tu supposes tout connaître tout de tout, ce n'est pas le comble de l'arrogance ?

Je donne mon opinion c'est un crime ?
Après que mes réponses posent des problèmes à certains je n'y suis pour rien.
On ne fait que discuter, pas besoin d'en faire un drama.

Le test a le même coût que la qualité, que l'on pourrait mettre dans le même panier. Tu cherches à prévenir de potentiels coûts futurs, sauf que ceux-ci ne se présenteront peut-être pas.

La maintenance a un coût et ce coût peut être réduit par une bonne couverture de test. C'est tout ce que je dis.
La maintenance n'est pas un coût potentiel futur, c'est un coût futur, point.
Pour le coup il ne s'agit pas d'opinion mais de faits.

Affirmer que l'assurance (qualité ou non) n'a pas de coût c'est simplement dire que les délais et les budgets tendent vers l'infini. Certains projets vivent très longtemps et d'autres sont au contraire très courts.

Jamais dit une chose pareille. Je dis que le coût des tests est généralement < coût de la maintenance. C'est une règle générale. Évidemment si ton projet a une durée de vie de 6 mois il faut moduler.

Oui sans équivoque, je dirais que pour une application bien testé, il y a 2-3 lignes de test pour 1 ligne de code. Donc à moins d'être 2-3x plus productif en test qu'en réalisation, c'est plus long d'écrire les TU que l'application.

Non.
Une seule ligne de code peut prendre 3 jours à écrire. Il n'y a pas de rapport entre la longueur d'un code et le temps de production.
Un test unitaire est rapide à écrire parce que c'est simple à écrire. Si c'est trop compliqué d'écrire un test c'est (généralement) une signal d'alarme que tu as un problème dans ton code.

Si maintenance il y a ... 100% de couverture par les TUs ne veut pas dire 0% de bugs.

C'est vrai ? Sans rire ?

Il faut donc que ton taux d'éviction des bugs par les TU soit supérieur au cout de la correction de l'ensemble des bugs à venir ... Et dans tout ce surcoût, tu as 0% de couverture en intégration à moyen, petite et grande échelle (voir plus haut mon exemple d'échelle).

Oui il faut moduler en fonction du besoin, mais généralement ...

Et rien n'empêche d'atteindre une très bonne couverture avec les TI.

Mouai je demande à voir ...

Filter les TUs c'est souvent compliqué car il faut analyser les dépendances entre packages alors que les dépendances modulaires sont déclaratives la plupart du temps.

Alors là je comprends pas. C'est quoi ta définition de test unitaire ?

Un test unitaire n'a par définition aucune dépendance. C'est même sa raison d'être. Je pense que tu t'es mal exprimé mais je vois pas du tout ce que tu veux dire ...

[*]Plus le build est complexe, plus je veux vérifier les problèmes d'intégration plutôt qu'unitaire (qui est le cadet de mes soucis), je fais confiance à chaque équipe pour me produire un produit de qualité "suffisant".

Ben écoute c'est bien, tu peux aussi aller à l'église et allumer un cierge si ça te tente (humour je précise)

A quoi fais-tu référence quand tu pas de "e2e" ?

Test fonctionnel. Ton moteur de test gère un parcours utilisateur programmé. Via Selenium par exemple.

Une petite question pour fixer une aile d'avion, tu aurais tendance à utiliser 1000 vis ou 100 rivets ?
Et pour fixer une étagère, 10 vis ou 1 rivet ?

Je suis pas assez mécano pour te répondre mais je sens que tu préfères les rivets

Aucun chance d'éliminer tous les bugs "unitaires" et toutes les chances de passer à côté des bugs d'intégrations ... Le bon moyen de rien voir venir avant le long terme !

J'ai jamais dit qu'il ne fallait pas de TI hein ...

Le rapport de temps entre TU/TI/TV n'étant pas de cet ordre de grandeur, je peux quand même livrer dans la journée un truc "propre" plutôt que 10 trucs crades dans la journée.
Exemples ou ce n'est pas applicable :

• Certaines organisations imposent un délai minimale entre la commande et la mise en production. Pour justement assurer la maturité du produit.
• Certains processus de livraison/mise en production nécessitent des intervenants externes qui facturent éventuellement à l'intervention (sans parler de planification). Il faut donc minimaliser la quantité (et en profiter pour améliorer la qualité).
• Certaines applications sont soumis à un SLA qui réduit grandement le temps et le nombre d'intervention.

Oui bien sûr qu'il y a des cas particuliers et qu'il faut faire fonction du contexte, je parle du cas général.

Si Amazon est capable de livrer une nouvelle version en prod toutes les 11 secondes et Facebook chaque jour c'est qu'il y a quand même une raison.

[Marco46]

Filter les TUs c'est souvent compliqué car il faut analyser les dépendances entre packages alors que les dépendances modulaires sont déclaratives la plupart du temps.

Alors là je comprends pas. C'est quoi ta définition de test unitaire ?

Un test unitaire n'a par définition aucune dépendance. C'est même sa raison d'être. Je pense que tu t'es mal exprimé mais je vois pas du tout ce que tu veux dire ...

Ah j'ai ptet une idée, tu voulais dire pour exécuter que les TU qui sont liés au module que tu veux tester ?

[Marco46]

Pour leur nature (TU ou autre), dans le cas d'un projet sur mesure pour un client, comme ça a été dit par skip, je préfère des tests macroscopiques qui simulent l'action d'un utilisateur (vous appelez ça TI, soit)

Ah non, un test d'intégration c'est un type de test qui couvre l'intégration d'un système avec un autre. L'utilisateur n'est pas dans la boucle à ce stade.
Par exemple un service web et une base de données, ou un service web et un autre service web, etc ...
Ca vérifie dans un environnement proche de la prod que les deux systèmes interagissent correctement entre eux, donc quand une bdd est dans la boucle ça veut dire lancer une bdd avec des données dedans (et tjs les mêmes pour que le test ait du sens, ce qui n'est pas sans poser des problèmes). Du coup forcément c'est un type de test qui est lent, beaucoup beaucoup beaucoup plus lent à l'exécution qu'un test unitaire. Mais il a son utilité qui est différente du TU.

C'est pour ça que quand je lis que untel préfère les TI aux TU ça me fait bondir parce qu'on compare des chats avec des mammouths.

Les tests où on simule un parcours utilisateur j'appelle ça des tests end-to-end (e2e), certains appellent ça des tests d'acceptance, d'autres des tests fonctionnels.
Cela rempli encore une utilité différente des TU et des TI.

et mettent en oeuvre toute la chaîne logicielle comme en prod, car le résultat du test pourrait montrer des problèmes très variés, et cela teste également les classes sous-jacentes dans leur contexte d'utilisation principal. Au final, il n'y a nécessité de faire des TU sur ces classes sous-jacentes (typiquement les classes métier) que si on les voit comme des composants réutilisables dans d'autres contextes (ce qui devrait être le cas d'un point de vue objet mais en pratique il y a souvent un couplage d'une façon ou d'une autre à leur contexte d'utilisation principal).
On utiliserait les TU plutôt dans le cas d'un projet de type "bibliothèque", ou l'API est clairement définie, et les tests unitaires corroborent la doc.

Est-il besoin de préciser que je suis en total désaccord avec ce que tu as écrit ?

Il faut noter aussi que faire des TU sereinement dans son projet, de la façon soutenue par Marco46, n'est possible que si on maîtrise le framework sous-jacent si il y en a un (c a d, il vaut mieux qu'il soit maison).

Ca suppose que les devs aient développé avec des patterns qui permettent (injection de dépendances) de tester unitairement. Cela n'a pas de rapport avec le framework applicatif. Le framework peut intégrer des mécanismes de lancement de tests (ou carrément de test tout court) mais c'est tout à fait faisable d'avoir des TU lancés par une tâche Ant par exemple avec un framework de test intégré en parallèle au framework de dev.

Bref, tes tests et les outils de tests (scripts, librairies genre JUnit) n'étant pas shippées dans le code de prod, il n'y a pas de dépendance entre ton code et la façon dont tu testes ton appli. Le seul critère bloquant c'est vraiment comment est structuré le code de ton application et ça ça dépend surtout du dev.

Autre problème avec la modification de logiciel open source, c'est qu'on a du mal à décider de la couverture de ses tests : il faudrait potentiellement écrire des tests pour les fonctionnalités du soft de base mais ce serait la folie ; ou sinon se poser avec le client et identifier point par point les fonctionnalités du soft de base qui vont être utiles, afin de réduire le nombre de tests.

Ca dépend complètement du projet et des gens qui gèrent. Pour AngularJS par exemple, je sais qu'une merge request sans test est systématiquement refusée aussi sympa soit-elle.

[Hirsiger]

Mouais... Si les 2% de non-qualité restants engendrent des bugs style Heartbleed, Ariane 5 ou Toyota Camry, je ne suis pas sûr que la balance penche du même côté.

Pour moi, la pertinence des TU a moins de rapport avec la taille du projet qu'avec sa criticité et le niveau de fiabilité dont on veut s'assurer.

Pour moi, heartbleed est à la fois un bug et une faille mais un outil tel que Lastpass fera l'affaire facilement. Par contre, il y a des failles beaucoup plus dangereuse comme la faille de winrar qui modifie l'extension du fichier "visible" à l'aide d'un éditeur hexadécimal.

[Luckyluke34]

Il faut noter une difficulté à décider de l'ensemble des tests, des fois c'est trop, des fois pas assez. Ça nécessite d'imaginer les éventuels problèmes avec une implémentation donnée (ou l'implémentation en cours ? c'est peut être un piège de croire ça.) Exemple, on sait que l'addition 2+2 fonctionne, on va pas tester 2+3, mais on peut considérer (car on a une idée de l'implémentation possible) que 2+0 pourrait provoquer des choses bizarres alors on le teste.

Oui, cette classification qu'on fait intuitivement a été théorisée dans un truc appelé equivalence partitioning. Mais il y a d'autres approches comme property-based testing où on teste systématiquement le maximum de valeurs possibles : on s'éloigne alors des tests basés sur des exemples pour aller vers le monde des théories. On "attaque" un théorème en le bombardant de valeurs et s'il tient, on peut considérer que ça se rapproche d'une preuve.

Il faut noter aussi que faire des TU sereinement dans son projet, de la façon soutenue par Marco46, n'est possible que si on maîtrise le framework sous-jacent si il y en a un (c a d, il vaut mieux qu'il soit maison). J'ai essentiellement bossé sur de la modification de logiciel open source, et du coup je ne pouvais pas me permettre de modifier le framework du soft de base pour faire en sorte qu'un mocking complet puisse être possible.

Si un framework se prête mal au mocking, on peut toujours ajouter des adapters ou wrappers autour de ses objets et mocker ces adapters à la place. En parallèle de ça, la validité du wrapper lui-même peut être testée individuellement en intégration avec le vrai framework (approche expliquée ici).

Autre problème avec la modification de logiciel open source, c'est qu'on a du mal à décider de la couverture de ses tests : il faudrait potentiellement écrire des tests pour les fonctionnalités du soft de base mais ce serait la folie ; ou sinon se poser avec le client et identifier point par point les fonctionnalités du soft de base qui vont être utiles, afin de réduire le nombre de tests.

Ca dépend de ce que tu appelles "soft de base", mais je dirais ne jamais tester la plateforme ou les frameworks tiers -- on suppose qu'ils sont corrects.

[Logan Mauzaize]

Oui tu ne testes pas la db via le TU (c'est le boulot des TI on est d'accord), tu testes la logique que tu peux avoir après la réponse de la db. Donc quand ta db te retourne un résultat ou une exception. Pour faire cela en TU il est bien nécessaire de mocker la DAO.

Pourquoi faire un TU si tu peux faire un TI ? En général toute la puissance est dans la requête, sans l'exécuter ca ne sert à rien.

Je parle de réalité comptable concrète pour le coup. Un projet a un début et une fin. Quand la fin arrive on fait le bilan et on voit ce que ça a couté. Tu peux donc savoir le poids de la maintenance dans un projet et prendre des mesures pour réduire ce poids. Augmenter la couverture de test fait parti des solutions.

La seule réalité c'est l'argent que tu souhaites dépenser à très court termes et celle que tu as déjà dépensé. Point. Le reste n'est qu'un mélange de spéculation, d'estimation et de projection. Attention, je parle bien de la "réalité comptable" et non de la gestion du risque.
La gestion du risque est nécessaire. Et, comme l'art du développement, ce n'est pas une science, il existe de nombreux leviers. Je te concède que la couverture des tests et le mise en place de TU (tu remarques la distinction entre les deux) n'en sont que des exemples. Mais ce ne sont pas (et ne doivent jamais être) considéré comme des panacées.
C'est cette dernière idée que je défendais (à travers 75% de mon message précédent).

On est d'accord, je n'ai peut être pas assez détaillé ma réponse ça me semblait assez évident.

Je préfère préciser, car je ne sais trop que combien c'est le cas

Il est évident que quand je dis couverture de code maximale, cela inclut la complexité, un test qui contient une assertion true === true ne sert à rien

Ce que j'entendais par là, c'est que j'ai vu des projets s'acharner à couvrir 100% de leur POJO (et autres trucs simplissimes, type passe-plat). Avec ce genre de procédé tu peux couvrir facilement 50-70% de lignes de code. En revanche quand tu regardes la couverture de la complexité, ca doit être à peine 30%. Et si tu prends la liste des modules, packages, classes ou méthodes et que tu tri par complexité avec un peu de chance t'auras un truc un peu couvert dans ton top 10.
C'est pourquoi mon réflexe après avoir fait l'analyse de couverture, c'est de trier par complexité et de vérifier que tout est bien couvert dans le top 10, 15 ou plus.

Je donne mon opinion c'est un crime ?
Après que mes réponses posent des problèmes à certains je n'y suis pour rien.
On ne fait que discuter, pas besoin d'en faire un drama.

Idem, tu poses une question j'y réponds Affirmer qu'en toute circonstance une proposition au sujet d'un projet est fausse, c'est simplement affirmer que tu connais tous les projets. Ce qui est une forme d'arrogance.

La maintenance a un coût et ce coût peut être réduit par une bonne couverture de test. C'est tout ce que je dis.
La maintenance n'est pas un coût potentiel futur, c'est un coût futur, point.
Pour le coup il ne s'agit pas d'opinion mais de faits.

On doit rire ou pleurer ?
Plus sérieusement, il y a des projets qui n'ont pas de maintenace. Et d'autres qui en ont peu.
De plus, maintenance évolutive ne veut pas dire corrective.
Autre point, la maintenance corrective n'est pas proportionnelle aux nombres de tests. On peut écrire un code d'excellente qualité (quantité de bugs) sans avoir aucun test. Par exemple, il existe les preuves formelles (ex : projet METEOR).

Jamais dit une chose pareille. Je dis que le coût des tests est généralement < coût de la maintenance. C'est une règle générale. Évidemment si ton projet a une durée de vie de 6 mois il faut moduler.

Sur l'ensemble du projet ça ne coute pas plus cher

Soit le coût est nul, soit il est amortissable. Pour qu'il soit amortissable (à coup sûr), il faut que l'activité tende vers l'infini. Les activités nécessitant temps et argent ... CQFD

Non.
Une seule ligne de code peut prendre 3 jours à écrire. Il n'y a pas de rapport entre la longueur d'un code et le temps de production.
Un test unitaire est rapide à écrire parce que c'est simple à écrire. Si c'est trop compliqué d'écrire un test c'est (généralement) une signal d'alarme que tu as un problème dans ton code.

Ou simplement que les cas sont complexes où nécessitent beaucoup de données. Aller un petit exemple pour la forme (désolé pour côté abstrait mais c'est confidentiel).
Admettons un graphe avec deux types d'arrêtes. Chaque arrête et chaque noeud dipose de ses propriétés. Un noeud peut avoir plusieurs instances d'un même type d'arrête. Le but d'une méthode est d'identifié la liste des sous-chemins parallèles (des arrêtes qui portent sur le même sujet mais de type différent).
Un exemple à la Cypher :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
(node1:Node)-[sujet1:Relation1]-(node2:Node)
(node1:Node)-[sujet1:Relation2]-(node2:Node)
(node2:Node)-[sujet1:Relation1]-(node3:Node)
(node2:Node)-[sujet1:Relation2]-(node3:Node)

Ca doit sortir le chemin ["node1", "node2"] pour "sujet1".
Rien de bien complexe à première vue sauf qu'il faut déjà initialiser le graphe. Deuxièmement, je l'ai abstrait sous la forme d'un graphe mais ca ne fonctionne pas tout à fait comme cela dans la réalité. Pour créer des relations ca demande un peu de travail, par ailleurs il ne s'agit pas d'un graphe mais de deux (un pour chaque type). Ensuite, la petite spécifité sinon ce serait trop facile, toutes les relations ne nous intéressent pas. Il faut donc casser certains chemins.

Bref, tout tient aisément en deux/trois méthodes à coder (pas nécessairement très complexes) mais pour tester, il faut à chaque fois construire un graphe. C'est limite plus simple d'alimenter la BDD pour le faire ; au moins on peut décrire les données sous formes XML. Bien entendu, on a mis en place des factory pour construire aisément des graphes d'objets mais ca reste tout de même du code de test.

Mouai je demande à voir ...

Les TI permettant de tester toutes les portes internes/externes de ton système, tu peux passer par toutes les combinaisons possibles. Si tu n'arrives pas à couvrir certaines parties, c'est que c'est du code mort.

Ben écoute c'est bien, tu peux aussi aller à l'église et allumer un cierge si ça te tente (humour je précise)

Je te retourne la plaisanterie ;-) Sauf que dans le cas de TI/TV je peux détecter n'importe quel bug avec tes TU non.

Test fonctionnel. Ton moteur de test gère un parcours utilisateur programmé. Via Selenium par exemple.

Effectivement pour le build d'une application, ca paraît un peu long. Mais sur un serveur d'intégration continue à la demande ou de manière périodique, ca ne fait pas de mal.

J'ai jamais dit qu'il ne fallait pas de TI hein ...

Juste qu'il ne servait à rien (ou presque) ? Comme je le disais de bon TI peuvent remplacer beaucoup de TU. Il faut adapter en fonction de la répartition de la complexité.
Néanmoins, selon tes dires, si la complexité est dans tes méthodes, c'est que le code est mal foutu ?

Si Amazon est capable de livrer une nouvelle version en prod toutes les 11 secondes et Facebook chaque jour c'est qu'il y a quand même une raison.

Mettre une nouvelle version en prod en 11 secondes, en soit ce n'est pas un miracle avec la bonne infrastructure. En revanche ca veut simplement dire passer d'un dépôt de binaire à l'environnement de production. Nul besoin d'avoir un build rapide. Et puis déployer une nouvelle version dans une infrastructure telle qu'Amazon n'a pas beaucoup de sens. Ca peut aussi bien être les WS, un composant dans la sphère ECx, le client Web, etc.

Ah j'ai ptet une idée, tu voulais dire pour exécuter que les TU qui sont liés au module que tu veux tester ?

Oui pour minimiser le temps d'exécution des tests (pour vérifier la non-régression), il est souvent utile d'analyser les impacts et de sélectionner les tests les plus représentatifs (ou écarter les moins significatifs). Pour les TV/e2e/acceptance/etc. on le fait généralement à la main avec beaucoup de feeling.
J'ai connu de gros projets où c'était automatisé en partie que ce soit pour les TV ou les TI, via des analyses de dépendances et d'impacts. Mais c'est très lourd à mettre en place. Je n'ose pas imaginer pour les TU.

Mais il a son utilité qui est différente du TU.
C'est pour ça que quand je lis que untel préfère les TI aux TU ça me fait bondir parce qu'on compare des chats avec des mammouths.
Les tests où on simule un parcours utilisateur j'appelle ça des tests end-to-end (e2e), certains appellent ça des tests d'acceptance, d'autres des tests fonctionnels.
Cela rempli encore une utilité différente des TU et des TI.

C'est tout ce qu'on voulait te voir écrire. Tu défendais bec-et-ongle les TUs, on disait simplement que les tests à plus haut niveau ont plus de valeurs car ils font tourner tout ou partie du système. Contrairement au TU qui ne font tourner que des blocs de code.

[Luckyluke34]

Soit le coût est nul, soit il est amortissable. Pour qu'il soit amortissable (à coup sûr), il faut que l'activité tende vers l'infini.

Je dirais plutôt que pour qu'il soit amortissable à coup sûr, il faut que le coût des tests soit inférieur au coût des bugs qui atteignent la prod si on ne fait pas ces tests. Par coût des bugs, j'entends coût de diagnostic, de résolution et coût des éventuels dégâts colatéraux en termes de chiffre d'affaires non réalisé, de mauvaise réputation du produit, éventuellement de failles de sécurité à corriger, etc.

Evidemment, le nombre et la gravité de ces bugs dépendent de la criticité et de la complexité du projet, de la techno, de la capacité de l'équipe de dev à faire du code de qualité sans tests (!)... donc c'est très très dur à évaluer avant.

Tu défendais bec-et-ongle les TUs, on disait simplement que les tests à plus haut niveau ont plus de valeurs car ils font tourner tout ou partie du système. Contrairement au TU qui ne font tourner que des blocs de code.

Les "problèmes" que je vois avec les tests d'intégration (ce qui ne veut pas dire qu'ils ne sont pas utiles) et qui font que pour moi les TU ont toujours leur place :

• "Voir le camp de départ, l'arrivée mais pas le terrain" : Il est plus difficile d'identifier les cas limites à tester, car plus compliqué de se représenter mentalement comment des valeurs d'entrée vont se propager et ce qu'elles vont déclencher dans tout un système que dans un seul objet. Il est aussi moins aisé d'imaginer comment un certain nombre de sous-composants pourraient faillir puisque le focus est sur le haut niveau. Ceci est d'autant plus vrai dans les applications propices aux side-effects où en cours de chemin on va faire de l'i/o, accéder à une base de données, un service web : autant de mini obstacles à prévoir et qu'on ne voit pas forcément de loin.

• Performance : Les tests d'intégration sont plus lents puisqu'ils impliquent plus de composants, et c'est encore pire si on inclut ceux qui vont chercher des données en base, sur le disque... Si on veut tester toutes les possibilités (scénarios nominaux, cas limites) dans ce cadre, on multiplie les tests lents et on a une suite de tests qui ne s'exécute plus en quelques secondes mais en minutes voire dizaines de minutes. La boucle de feedback devient poussive et on hésite davantage à faire des modifications car on sait qu'il peut se passer pas mal de temps avant de se rendre compte qu'on a tout cassé.

• Complexité : Plus les objets sont réutilisés dans différents scénarios au sein de différents graphes (et on sait que la réutilisation c'est plutôt bien), plus les tests d'intégration vont se complexifier. De la duplication va apparaitre dans l'étape de Setup des tests d'intégration puisque le même objet va devoir être instancié et arrangé dans de multiples tests. On pourrait dire qu'il suffit de créer des méthodes helpers de test communes pour effacer cette duplication, mais un problème se pose quand on s'aperçoit qu'il doit être arrangé d'une certaine manière dans un test A, d'une autre dans un test B et encore une autre dans un test C. Ceci multiplié par le nombre d'objets intermédiaires dans le graphe sur lequel porte le tests d'intégration, et si on veut gérer tous les cas, on aboutit souvent à des Setup de tests obèses, qui varient seulement un petit peu à chaque fois.

• Facilité de diagnostic : Un test d'intégration qui échoue va nécessiter d'analyser une stack trace pour remonter à l'objet défaillant, voire de débugger, alors qu'un test unitaire bien nommé et avec des assertions précises va bien souvent nous amener directement au bloc de code concerné.

• Rythme de développement : C'est là qu'on peut reboucler avec le sujet d'origine qui est TDD. Quand on écrit les tests avant, on peut considérer chaque boucle "écriture des tests puis du code" comme un fossé qu'on se creuse pour essayer de le franchir ensuite. C'est très agréable quand on peut évoluer par bonds, petit fossé par petit fossé (TU). On n'est jamais loin du bord pour se rattraper en cas de chute. Si ces fossés deviennent de vastes précipices (tests d'intégration) car le travail nécessaire pour faire passer un test s'étend sur des dizaines de minutes ou des heures, ça devient beaucoup plus hasardeux et laborieux, et surtout plus compliqué de faire marche arrière pour repartir sur des bases saines.

Bilan : pour moi il faut des tests haut niveau mais pas que, et il faut des TU, mais pas que.

[Luckyluke34]

Un exemple à la Cypher :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
(node1:Node)-[sujet1:Relation1]-(node2:Node)
(node1:Node)-[sujet1:Relation2]-(node2:Node)
(node2:Node)-[sujet1:Relation1]-(node3:Node)
(node2:Node)-[sujet1:Relation2]-(node3:Node)

Ca doit sortir le chemin ["node1", "node2"] pour "sujet1".
Rien de bien complexe à première vue sauf qu'il faut déjà initialiser le graphe. Deuxièmement, je l'ai abstrait sous la forme d'un graphe mais ca ne fonctionne pas tout à fait comme cela dans la réalité. Pour créer des relations ca demande un peu de travail, par ailleurs il ne s'agit pas d'un graphe mais de deux (un pour chaque type). Ensuite, la petite spécifité sinon ce serait trop facile, toutes les relations ne nous intéressent pas. Il faut donc casser certains chemins.

Bref, tout tient aisément en deux/trois méthodes à coder (pas nécessairement très complexes) mais pour tester, il faut à chaque fois construire un graphe. C'est limite plus simple d'alimenter la BDD pour le faire ; au moins on peut décrire les données sous formes XML. Bien entendu, on a mis en place des factory pour construire aisément des graphes d'objets mais ca reste tout de même du code de test.

Je pense que ça reste des tests unitaires (sauf si tu reconstruis les graphes depuis la base en faisant appel à un autre objet pour l'accès aux données). La structure de données d'un graphe est composite, mais pour autant ses parties - noeuds, arêtes - ne sont pas des objets ayant un comportement, donc une validité à tester. Ce sont juste des réceptacles pour des données.

Les tests vont certes nécessiter de "monter" le graphe au préalable, mais ce montage ne qualifie pas le test comme un test d'intégration à mon sens puisqu'on ne repose pas sur une quelconque validité comportementale des objets Noeud et Arête pour tester l'algo qui liste les sous-chemins parallèles.

[Logan Mauzaize]

donc c'est très très dur à évaluer avant.

C'est pourquoi on fait appel à la gestion de projet qui évalue les risques.

"Voir le camp de départ, l'arrivée mais pas le terrain" : Il est plus difficile d'identifier les cas limites à tester, car plus compliqué de se représenter mentalement comment des valeurs d'entrée vont se propager et ce qu'elles vont déclencher dans tout un système que dans un seul objet. Il est aussi moins aisé d'imaginer comment un certain nombre de sous-composants pourraient faillir puisque le focus est sur le haut niveau. Ceci est d'autant plus vrai dans les applications propices aux side-effects où en cours de chemin on va faire de l'i/o, accéder à une base de données, un service web : autant de mini obstacles à prévoir et qu'on ne voit pas forcément de loin.

Premièrement je ne fais pas une grosse distinction entre les types de tests M2M. Ce n'est qu'une question d'échelle. J'adopte un point de vue purement systémique. Que j'accède à un objet, un composant, un module, un service web, une base de données, un disque, etc. il n'y a aucune différence, ce n'est qu'un système qui dispose de propriétés et/ou rends des services. Accéder à un W-S, accédera à un objet qui invoquera la BDD qui fera un accès disque.
Si tu bouchonnes en TU, tu peux également le faire en TI, c'est simplement un changement d'échelle.
Idem si j'ai plusieurs gestionnaires/services et que j'ai des algos qui reposent sur une combinaison, les tests de ces algos sont des TU ou des TI ? Encore une question d'échelle.
Partant du principe boite blanche/grise/noire, je me moque des états internes. Ce que je vérifie c'est que jouant des actions précises sur mon système, son environnement en perçoivent correctement les modifications.

A ce titre, d'ailleurs, j'aime bien violé (en partie) l'un des principes du TU : la reproductibilité ; j'applique le Fuzzing. Cette technique est bien adapté justement aux tests de bibliothèques (dont il était question précédemment). Bien entendu en cas d'échec, le minimum c'est de sauvegarder les entrées générées pour lancer un debug (et selon TDD, créer le test qui correspond à ces entrées) ; et l'idéal de sauvegarder l'état du système au moment de l'échec. Associer à l'intégration continue, cela permet de bien stresser le code.
Pour les adeptes de JUnit, les "Theories" s'y prêtent particulièrement bien.

Performance : Les tests d'intégration sont plus lents puisqu'ils impliquent plus de composants, et c'est encore pire si on inclut ceux qui vont chercher des données en base, sur le disque... Si on veut tester toutes les possibilités (scénarios nominaux, cas limites) dans ce cadre, on multiplie les tests lents et on a une suite de tests qui ne s'exécute plus en quelques secondes mais en minutes voire dizaines de minutes. La boucle de feedback devient poussive et on hésite davantage à faire des modifications car on sait qu'il peut se passer pas mal de temps avant de se rendre compte qu'on a tout cassé.

En général c'est une méconnaissance de la gestion des tests. Je recommande fortement dès qu'une batterie de test devient trop importante de catégoriser des tests, voir de créer des tests spécifiques pour vérifier : robustesse, non-régression, performance, etc.
D'ailleurs tu soulèves un point intéressant : la boucle de feedback. C'est l'un des points les plus intéressants avec les tests (TU ou autres).

Complexité : Plus les objets sont réutilisés dans différents scénarios au sein de différents graphes (et on sait que la réutilisation c'est plutôt bien), plus les tests d'intégration vont se complexifier. De la duplication va apparaitre dans l'étape de Setup des tests d'intégration puisque le même objet va devoir être instancié et arrangé dans de multiples tests. On pourrait dire qu'il suffit de créer des méthodes helpers de test communes pour effacer cette duplication, mais un problème se pose quand on s'aperçoit qu'il doit être arrangé d'une certaine manière dans un test A, d'une autre dans un test B et encore une autre dans un test C. Ceci multiplié par le nombre d'objets intermédiaires dans le graphe sur lequel porte le tests d'intégration, et si on veut gérer tous les cas, on aboutit souvent à des Setup de tests obèses, qui varient seulement un petit peu à chaque fois.

Même problème avec les TUs quand il faut mocker à tout va. Néanmoins c'est le plus gros problème avec les tests en général comme exprimer simplement et clairement l'état de départ du/des systèmes.
Tout cela nécessite, en général, la mise en place de ce que j'appelle le "test framework". Il ne s'agit pas de coder JUnit, TestNG ou autre. Mais bien de mettre en place un ensemble d'API dédié aux tests. Ce qui est assez marrant, c'est qu'à coup sûr du code de l'API de test va migrer vers le code de production. Attention, je ne limite pas l'API de test à du code (ex: JUnit) mais aussi à des fichiers XML, des scripts Ant/Shell, etc.

Facilité de diagnostic : Un test d'intégration qui échoue va nécessiter d'analyser une stack trace pour remonter à l'objet défaillant, voire de débugger, alors qu'un test unitaire bien nommé et avec des assertions précises va bien souvent nous amener directement au bloc de code concerné.

Encore une question d'échelle. Certains bugs ne sont pas détectables avec des TUs. Donc un bon TI avec des assertions précises t’amènera directement au module concerné.

Rythme de développement : C'est là qu'on peut reboucler avec le sujet d'origine qui est TDD. Quand on écrit les tests avant, on peut considérer chaque boucle "écriture des tests puis du code" comme un fossé qu'on se creuse pour essayer de le franchir ensuite. C'est très agréable quand on peut évoluer par bonds, petit fossé par petit fossé (TU). On n'est jamais loin du bord pour se rattraper en cas de chute. Si ces fossés deviennent de vastes précipices (tests d'intégration) car le travail nécessaire pour faire passer un test s'étend sur des dizaines de minutes ou des heures, ça devient beaucoup plus hasardeux et laborieux, et surtout plus compliqué de faire marche arrière pour repartir sur des bases saines.

Merci enfin pour ce retour à l'échelle. Néanmoins, j'avais plus dans l'idée un pont de singe. Qu'on rendait plus ou moins stable (confiant) en contrôlant la quantité de tests (quelque soit le type).

Bilan : pour moi il faut des tests haut niveau mais pas que, et il faut des TU, mais pas que.

Amen ! Mince on a dit pas de dogmatisme ...

[Logan Mauzaize]

Je pense que ça reste des tests unitaires (sauf si tu reconstruis les graphes depuis la base en faisant appel à un autre objet pour l'accès aux données). La structure de données d'un graphe est composite, mais pour autant ses parties - noeuds, arêtes - ne sont pas des objets ayant un comportement, donc une validité à tester. Ce sont juste des réceptacles pour des données.

Les tests vont certes nécessiter de "monter" le graphe au préalable, mais ce montage ne qualifie pas le test comme un test d'intégration à mon sens puisqu'on ne repose pas sur une quelconque validité comportementale des objets Noeud et Arête pour tester l'algo qui liste les sous-chemins parallèles.

Je parlais bien de la complexité des TUs !

[Marco46]

C'est tout ce qu'on voulait te voir écrire. Tu défendais bec-et-ongle les TUs, on disait simplement que les tests à plus haut niveau ont plus de valeurs car ils font tourner tout ou partie du système. Contrairement au TU qui ne font tourner que des blocs de code.

C'est ce que je dis depuis le début mais bon ... A ceci près que je dis également que je ne vois aucune bonne raison de se passer des TU.

Les TI sont tout aussi nécessaire, au minimum un par point d'entrée, mais je ne vois pas comment s'abstraire des TU.

Ce que j'entendais par là, c'est que j'ai vu des projets s'acharner à couvrir 100% de leur POJO.

Un POJO n'est pas censé contenir de logique, il n'y a donc rien à tester.

(et autres trucs simplissimes, type passe-plat)

Dans un passe plat il y a les affectations à tester. De toutes façons tu vas bien devoir le tester au minimum manuellement, a moins de livrer sans faire de vérification ?
Donc autant avoir un test réutilisable pour toute les fois où tu feras une modif non ?


Pour le reste inutile de continuer je pense.

[Luckyluke34]

A ce titre, d'ailleurs, j'aime bien violé (en partie) l'un des principes du TU : la reproductibilité ; j'applique le Fuzzing. Cette technique est bien adapté justement aux tests de bibliothèques (dont il était question précédemment). Bien entendu en cas d'échec, le minimum c'est de sauvegarder les entrées générées pour lancer un debug (et selon TDD, créer le test qui correspond à ces entrées) ; et l'idéal de sauvegarder l'état du système au moment de l'échec. Associer à l'intégration continue, cela permet de bien stresser le code.
Pour les adeptes de JUnit, les "Theories" s'y prêtent particulièrement bien.

Oui, c'est ce que j'évoquais avec le Property-based testing. La famille des bibliothèques de test *Check dans les langages fonctionnels permet le même genre de choses.

En général c'est une méconnaissance de la gestion des tests. Je recommande fortement dès qu'une batterie de test devient trop importante de catégoriser des tests, voir de créer des tests spécifiques pour vérifier : robustesse, non-régression, performance, etc.

Oui, mais comment savoir quelle catégorie de tests lancer après une modif ? Comment être sûr que le découpage en catégories est fiable et qu'un test dans une catégorie a priori non liée à la modif en cours ne va pas échouer ? Jusqu'où va cette exécution sélective des tests ? Uniquement sur le poste de dev ? Si le serveur d'intégration continue exécute lui systématiquement toute la suite, ne risque-t-on pas d'avoir des builds très longs et des problèmes de concurrence de commits ?

Même problème avec les TUs quand il faut mocker à tout va.

Même problème, mais à bien moindre échelle. Une classe va typiquement avoir un ou deux collaborateurs donc la complexité sera limitée. "Mocker à tout va" est d'ailleurs sans doute révélateur d'un problème de design - notre objet en fait probablement trop, il a trop de dépendances.

Tout cela nécessite, en général, la mise en place de ce que j'appelle le "test framework". Il ne s'agit pas de coder JUnit, TestNG ou autre. Mais bien de mettre en place un ensemble d'API dédié aux tests. Ce qui est assez marrant, c'est qu'à coup sûr du code de l'API de test va migrer vers le code de production. Attention, je ne limite pas l'API de test à du code (ex: JUnit) mais aussi à des fichiers XML, des scripts Ant/Shell, etc.

100 % d'accord.

Certains bugs ne sont pas détectables avec des TUs.

Oui, ce sont les bugs à la périphérie ou à la lisière de l'application, à savoir défaillance hardware ou réseau, défaillance de système tiers ou problème de configuration. Il faut des tests d'intégration pour ces cas. En général, j'isole ces composants externes via un wrapper ou adapter et je teste le wrapper en intégration.

Donc un bon TI avec des assertions précises t’amènera directement au module concerné.

Le problème étant que plus le TI porte sur un vaste système, plus ces assertions seront nombreuses. Faut-il les mettre toutes dans le même test au point de le rendre peu lisible ? Dans des tests séparés ? Et surtout, si un sous-système s est testé par des assertions des TI d'un système S1, faut-il les retester dans les TI de S2 dans lequel s est aussi utilisé ? Si non, comment repérer ces chevauchements ?