Discussion :

[Marco46]

On va reprendre, tu dis :

Le sujet n'est pas "Les Test Unitaires".. mais "L'excès de tests unitaires nuit au développement agile". On est donc dans un contexte particulier..

Toi tu nous dis pas que l'excès de TU nuit à l'agile mais que les TU nuisent à l'agile, c'est pas pareil !

J'en veux pour preuve :

Je ne vois pas pourquuoi associer les TU et agilité : les TU proviennent du cycle en V... C'est une bonne chose dans certains cas, une mauvaise dans d'autres.

Ils sont une composante obligatoire de l'agilité, parce qu'ils permettent l'agilité.

Pourquoi ?

Parce que les TU sont les plus rapides à exécuter, donc pour tester vite et déployer vite ils sont préférables aux autres types de tests, ce qui ne signifie pas qu'il ne faut pas d'autres types de tests.

Les TU sont utiles pour les opérations complexes, les unités complexes impliquant un calcul particulier, l'application d'une méthode particulière..

Oui mais pas que.

Faire des TU pour vérifier que la fonction A+B fait bien A+B est stupide, et une perte de temps et d'argent phénoménale - ou alors c'est que vous n'avez pas confiance dans votre équipe, et alors votre équipe n'est en rien basée sur l'Agilité.

Sur les opérations vraiment simples on peut débattre pour savoir qu'est ce qui relève de l'excès, c'est ce que dit l'auteur et je veux bien l'entendre mais c'est pas ce que tu dis toi.

D'autre part, la documentation des TU doit être réduite à sa plus simple expression : "passé le test le DD/MM/YYY à hh:mm", sans plus.. En mettre plus est bêtement du recopiage du cycle en V dans sa plus lourde et pénible - et lente - expression..

Personne a dit qu'il fallait blinder les TU de doc. C'est toi qui sors ça de ton chapeau.

Les TU sont un reliquat du cycle en V, qui simplement reposent sur 4 éléments qui ne font pas partie de l'Agilité mais du modèle en cascade : d'une part que toute personne est remplaçable à tout moment, secondo que tout doit être documenté/analysé avant de le faire, tertio que il y a un ordre logique et immuable dans les opérations, et quarto que le programmeur est "irresponsable" et que seule la doc et le chef sont responsables...

Non, invention de ta part.

Y accorder une importance en termes de projet est stupide et anti-agilité :

Non, ce qui est stupide et contre productif c'est de ne pas en faire ou de ne pas en faire assez, surtout en mode agile.

soit les personnes de l'équipe sont responsables, et alors on leur fait confiance pour faire des TU lorsque ils le jugent nécessaire - unité complexe -, et alors on est agile, soit les personnes de l'équipe sont irresponsables, et alors on doit surveiller de l'extérieur leur avancement et leur programmation, et on oblige à faire tous les TU documentés de chaque unité, et alors on est dans un schéma anti-agilité.

Ca c'est au chef de projet de définir le niveau de qualité qu'il veut. Ce n'est pas aux développeurs de décider ça unilatéralement.

[Luckyluke34]

Tu avait une vision de projet que Souviron et moi n'avons pas. (je suis d'ailleurs content de trouver un camarade qui semble savoir ce qu'est un gros projet)
Il y a des projets qui sont énormes (d'ailleurs en réponse à mon premier post tu ne me croyais pas et il a fallu que j'indique que ce n'était que des chiffres sortis d'un projet existant)

Je ne suis pas persuadé qu'un concours de kiki de qui a le plus gros projet apporte grand chose à ce débat (ni à d'autres d'ailleurs)

Quand on dit "il n'y a pas de rapport entre la taille d'un projet et les tests unitaires", c'est que la valeur apportée par les TU n'est pas fonction du nombre de lignes de ton projet. Si un médecin estime nécessaire de changer ses gants entre chaque patient, il ne va pas arrêter de le faire parce qu'il a 50 patients au lieu de 10 dans une journée.

Or quand un projet est vendu, le temps associé pour le réaliser compte rarement le temps réel pour faire les tests.
Il faut donc converger sur ce qu'il y a de plus judicieux et de plus rapide.

Peut-être, mais je reste persuadé que les tests unitaires permettent de penser en profondeur une unité de code, ses cas nominaux mais aussi ses cas limites, les plages de valeurs valides, de mettre à jour ses dépendances implicites et explicites pour mieux les agencer...

Plus particulièrement, selon mon expérience, écrire un test unitaire avant le code correspondant permet de concevoir son code en étant focalisé sur une seule fonctionnalité à faire passer et d'être sûr qu'elle marche. Avec un test écrit après, a fortiori un test grosse maille, on travaille plus au jugé en risquant de mésestimer tous les cas qui se produiront à l'exécution.

[Marco46]

Or quand un projet est vendu, le temps associé pour le réaliser compte rarement le temps réel pour faire les tests.
Il faut donc converger sur ce qu'il y a de plus judicieux et de plus rapide.

Relire ses classiques d'abord.

[transgohan]

Relire ses classiques d'abord.

C'est du foutage de gueule non ? Je vous laisse débattre entre vous...
Il semble que vous ayez réponse à tout et êtes à même de mener n'importe quel projet à bien avec votre méthode.
J'espère simplement qu'on ne travaillera jamais sur le même projet...
A bon entendeur.