J'ai fait partie de nombreuses équipes qui tentent de pratiquer des méthodologies Agiles et souvent ces équipes sont centrées sur les tests. Le test est-il une partie nécessaire de la pratique de la méthodologie Agile ou est-ce juste une pratique XP qui a été maintenue au fil des ans?

Les tests sont absolument essentiels à l'agile, principalement parce que l'agile est basé sur des améliorations incrémentielles: la difficulté est qu'il peut parfois être difficile de voir comment les modifications actuelles affecteront votre ancien code. La meilleure façon de vous assurer que vous n'avez pas cassé quelque chose est de le tester et de savoir COMMENT le tester. De cette façon, vous trouvez le bogue immédiatement, pas sur la route lorsque vous avez oublié exactement ce que vous avez fait lorsque vous écriviez le code qui a cassé une ancienne fonctionnalité.

La raison pour laquelle cela diffère de la programmation de conception descendante plus traditionnelle est que dans cet environnement, il a) est très difficile à tester jusqu'à ce que vous ayez le produit fini b) en théorie, vous considérez tous les critères de conception en même temps, et vous êtes donc moins susceptible de prendre une décision de conception qui rompt les décisions de conception précédentes.

Vous parlez probablement de tests automatisés, de tests unitaires, de tests d'intégration, etc. Ceux-ci sont plus importants pour les tests agiles que manuels (avec des testeurs et autres) car ils sont trop lents, il n'est donc pas possible de tester chaque petite modification que vous apportez. Étant donné que l'agilité consiste à effectuer de petites itérations rapides, il est très utile de disposer de tests qui vérifient l'exactitude en secondes ou minutes, plutôt qu'en heures ou jours.

Si vous n'avez pas de tests, comment savez-vous que votre code fonctionne?

Edit: l'affirmation selon laquelle les tests ne peuvent pas prouver que le code fonctionne ne définit pas un terme crucial, à savoir les travaux . Qu'est-ce que cela signifie pour un programme de fonctionner? Si vous gardez ce terme vague, il n'y a aucun moyen de prouver ou d'être sûr que n'importe quel programme fonctionne. Déjà.

D'autre part, vous pouvez définir les œuvres comme "se comporte selon une spécification". Maintenant, vous pouvez non seulement utiliser des tests pour montrer que le code fonctionne, mais les tests eux-mêmes peuvent servir de spécification exécutable du comportement de votre code. En d'autres termes, une suite de tests bien écrite définit ce qui fonctionne .

Cette façon de penser vous oblige également à réexaminer la signification d'un bug . Si votre code passe tous les tests, il n'y a pas de bogues dans le code. Si, malgré cela, le système ne se comporte pas comme il se doit, alors son comportement n'est pas correctement spécifié. C'est à dire. le bug est dans la spécification, définie par des tests.

Cette approche du développement logiciel dissocie la spécification fonctionnelle d'un système de sa mise en œuvre, ce qui, selon tous les livres de génie logiciel dans le monde, est une très bonne chose. Dans le même temps, cette approche garantit que votre implémentation correspond toujours à la spécification fonctionnelle.

Non, ce n'est pas nécéssaire"

Les principes d'Agile ne disent rien directement sur les tests.

Mais c'est fortement recommandé

Étant donné l'engagement d'Agile envers un processus durable, une livraison continue / incrémentielle et la qualité des logiciels, les tests automatisés sont la meilleure solution actuellement disponible pour la plupart des projets

Les exceptions (comme l'a noté Jörg W Mittag) incluent les outils de développement prouvés corrects, les systèmes de méta-programmation qui génèrent du code, et al. Mais ces types de systèmes sont rares.

Agile et XP tentent tous deux d'éviter Big Design Up Front . Dans BDUF, les exigences sont rassemblées, une spécification formelle est créée, puis le codage est fait, puis tests sont effectués. Cela a du sens pour des systèmes bien définis, essentiels à la mission et à la vie, comme l'équipement médical, les sondes spatiales, etc.

Agile évite ce flux car il ne fonctionne pas bien pour des problèmes qui ne sont pas bien définis, par exemple "quels que soient les changements demandés par le client cette semaine". Nous avons encore besoin d'une spécification formelle, donc nous savons quoi faire et quand nous avons terminé, mais plutôt que d'une sorte de document écrit, nous utilisons du code sous la forme de tests automatisés.

Les tests unitaires automatisés sont rapides à écrire, rapides à exécuter et très modulaires / découplés. Cela en fait un moyen rapide de spécifier et de vérifier formellement les exigences.