Agile sans tests unitaires

Est-il judicieux de parler de «développement agile» ou de prétendre que vous appliquez une «méthodologie agile» si la base de code sur laquelle vous travaillez a une couverture de test unitaire de 0%? (Et vous, en tant qu'équipe, ne faites rien à ce sujet).

Pour être clair: pour moi, cela n'a pas de sens. Dans mon expérience personnelle, j'ai trouvé que les tests unitaires sont le seul outil qui vous permet d'être vraiment "agile" (c'est-à-dire répondre aux changements, améliorer votre conception, partager les connaissances, etc ...) et TDD est la seule pratique qui vous y emmène. .

Il y a peut-être d'autres façons, mais je ne vois toujours pas comment elles peuvent fonctionner.

Pour être pédant, rien dans le Manifeste Agile ou le Guide Scrum ne fait référence aux pratiques techniques, comme les tests unitaires ou TDD, du tout. Donc, oui, en théorie, vous pourriez livrer tôt et souvent en mettant l'accent sur la collaboration et la valeur sans eux et vous appeler Agile, vous pourriez même avoir de l' agilité .

En pratique cependant, il est presque impossible de fournir de la valeur de manière cohérente ( en production ) toutes les quelques semaines sans une bonne suite de tests. Cela inclut les tests d'intégration ainsi que les tests unitaires. Les tests unitaires ne vont que jusqu'à présent. Il y a une raison pour laquelle c'est une pyramide et non un rectangle après tout.

Sans les tests en tant que filet de sécurité, vous introduirez de nombreux bogues de régression dans chaque version ou serez terrifié par la refactorisation. Les deux auront un impact considérable sur votre capacité à continuer à un rythme durable . Si vous ne pouvez pas maintenir votre rythme ou changer de cap (refonte) si nécessaire, alors vous n'avez pas d'agilité. L'agilité, après tout, est l'objectif que nous visons.

Le manifeste agile déclare simplement:

Individus et interactions sur les processus et les outils

Logiciel de travail sur une documentation complète

Collaboration client sur négociation de contrat

Répondre au changement suite à un plan

Aucune mention de tests unitaires là-bas. Même les 12 principes ne mentionnent pas les tests.

Donc, techniquement, il est possible d'être une équipe agile sans écrire de tests unitaires. En pratique cependant, il est vraiment difficile de voir comment une équipe peut maintenir un logiciel fonctionnel dans un environnement agile sans tests pour l'aider à effectuer des changements constants.

Même s'il n'y a pas de mot direct sur les tests unitaires ou TDD ou tout type de test dans le manifeste agile comme d'autres l'ont répondu ici, je crois qu'un bon Scrum Master ou développeur serait capable de discerner l'une des déclarations du manifeste.

Logiciel de travail  sur une documentation complète.

Comment savoir si le logiciel fonctionne? Le manifeste n'a pas besoin d'indiquer explicitement le terme test. C'est succinct.

Les tests unitaires (dans le contexte du sujet) ralentiront votre phase de codage à l'étape précédente, mais en valent la peine à mesure que vous progressez, ce qui accélère le développement. Il vous donne un contrôle fin du grain sur les tests de niveau de code et rend votre conception évolutive, vous donnant l'assurance que votre logiciel fonctionne et peut facilement gérer la régression; ce qui rendrait votre développement agile.

C'est tout à fait logique. Agile ne consiste pas à tester, comme d'autres l'ont déjà mentionné, mais à répondre spécifiquement à votre question:

Non, vous n'avez absolument pas besoin de tests unitaires.

Vous pouvez exécuter un processus agile avec des tests d'intégration uniquement. Vous pouvez par exemple exécuter un test d'intégration automatisé tous les soirs et corriger les bogues détectés le lendemain. Vous pouvez avoir un testeur manuel exécutant des tests d'intégration en continu si vous le souhaitez. Quel que soit le système, le test unitaire est entièrement facultatif.

Vous trouverez peut-être que les tests unitaires vous aident à développer, et assez juste pour cela, mais il y a beaucoup de choses qui peuvent aider au développement que vous pourriez ne pas avoir.

Vous avez besoin d'une certaine forme de test, même si ce sont les anciens «testeurs bêta clients». Si votre client est fortement impliqué dans le processus et ne craint pas de trouver des bogues, alors cela peut fonctionner - car ils ont tendance à trouver des bogues que personne d'autre ne pensait être des bogues!

Ce n'est pas obligatoire. Les tests sont excellents lorsque des personnes savent vraiment comment les utiliser. Lorsque vous ne le faites pas, non seulement ce n'est pas nécessaire, cela devient un passif. Je dirais qu'il y a beaucoup de programmeurs qui ne sont pas très compétents.

Je suis heureux que vous ayez reconnu dans votre question qu'être agile, c'est comment vous publiez réellement un logiciel au lieu de suivre une méthodologie. Le Manifeste Agile est une belle référence, mais ce n'est pas le guide définitif. L'agilité existait avant elle. Il existe des moyens de développer un logiciel pour être "plus agile" mais différentes combinaisons peuvent être utilisées sur différents projets.

Si vous publiez un nouveau logiciel à un rythme acceptable pour le client, vous êtes probablement agile. J'inclurais également de ne pas avoir trop de recul et de me plaindre des changements de fonctionnalités par les développeurs. Réparer une chose pour en casser une autre n'est pas idéal non plus. Lorsque vous êtes plusieurs utilisateurs derrière la mise à niveau, vous n'êtes probablement pas très agile, que vous testiez ou non.

Je voudrais contredire (autres réponses) que le manifeste Agile énonce clairement quelque chose à ce sujet, à savoir:

Une attention continue à l'excellence technique et à une bonne conception améliore l'agilité.

J'aime beaucoup la définition LeSS de l'excellence technique et elle comprend les tests unitaires et TDD. Vous pouvez maintenant affirmer que vous pourriez ne pas avoir besoin de tests unitaires et / ou TDD pour y parvenir, mais c'est la façon la plus courante et probablement conseillée.

L'agilité organisationnelle est limitée par l'agilité technique

En d'autres termes, lorsque vous tardez à apporter des modifications à votre produit, peu importe la façon dont vous structurez vos équipes, votre organisation ou le cadre que vous adoptez, vous serez lent à répondre aux changements.

Si vous pouvez empêcher votre produit de résister au changement d'une autre manière, vous pourriez être sur la bonne voie, mais:

J'ai inventé la programmation extrême pour rendre le monde sûr pour les programmeurs. - Kent Beck

Scrum n'a aucune pratique technique, mais Jeff a dit ce qui suit à ce sujet:

Je n'ai jamais vu une équipe Scrum hyper-productive qui n'utilisait pas les pratiques de développement Extreme Programming. - Jeff Sutherland

Cité de cet article: http://ronjeffries.com/articles/017-02ff/gathering2017/

Je m'attendrais à ce que les équipes Scrum sans pratiques techniques finissent par utiliser des rétrospectives avec une pratique similaire. Vous voulez aussi être hyper-productif, non?

Le modèle de fluence Agile , le mentionne au niveau deux étoiles:

Les techniques utiles incluent l'intégration continue, le développement piloté par les tests , la programmation par paires et la propriété collective.

Si vous ne ciblez que le premier niveau de fluidité Agile, vous pouvez ignorer la pratique, mais tout produit plus grand et plus long devrait au moins essayer d'atteindre un niveau deux étoiles.

Ainsi, le consensus général est que oui sans bonnes tests unitaires, code propre et pratiques de refactorisation, il n'est actuellement pas possible d'être vraiment Agile. Cela pourrait changer à l'avenir avec l'émergence de nouvelles pratiques techniques.

Selon vous, quelle serait la réponse si nous demandions à certains signataires du manifeste comme Robert C. Martin, Martin Fowler ou Kent Beck? Ils diront peut-être que cela dépend, mais en général, c'est quelque chose que vous devez faire.