BT

Diffuser les connaissances et l'innovation dans le développement logiciel d'entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Améliorer La Testabilité  : Supprimer Les Anti-Patterns Grâce À Des Conversations Conjointes

Améliorer La Testabilité  : Supprimer Les Anti-Patterns Grâce À Des Conversations Conjointes

Favoris

Points Clés

  • Le code est toujours testable en identifiant les anti-modèles et en les corrigeant.
  • La testabilité de la conception et du code affecte la capacité à automatiser les tests.
  • Les décisions de conception sont prises par les développeurs, et les testeurs peuvent les influencer pour une meilleure testabilité.
  • Les pratiques de code propre et la testabilité vont de pair afin que les développeurs et les testeurs puissent en bénéficier.
  • Les discussions conjointes en cours entre les développeurs et les testeurs peuvent aider à améliorer la testabilité,
  • Les chefs d'équipe et les managers doivent favoriser les discussions conjointes dans le cadre des processus d'amélioration.

 

Lorsque nous écrivons des tests automatisés, nous pouvons rencontrer des problèmes. Les tests ne passeront pas, ou nous passerons beaucoup de temps à faire l'effort. « Ce code n'est pas testable », dirions-nous. Surtout, ce n'est pas vrai. Le code est toujours testable, mais le coût peut être élevé et l'effort épuisant.

La bonne nouvelle est que nous pouvons modifier le code pour qu'il soit hautement testable, en identifiant les anti-patterns et en les corrigeant. La meilleure nouvelle est que nous, les développeurs, pouvons faire en sorte que le code corresponde aux exigences du test, en discutant avec les testeurs, qui le testent réellement.

Les testeurs peuvent-ils vraiment affecter la façon dont le code est écrit ?

Cela dépend vraiment de la relation entre les testeurs et les développeurs. Dans une équipe agile et cohésive, il y a une ouverture d'esprit. Mais dans de nombreux cas, les testeurs obtiennent leur code « prêt à tester », des semaines ou des mois après que les développeurs aient fini de programmer. À ce stade, demander aux développeurs de "remonter le temps", de laisser ce qu'ils font et de changer ce qu'ils considèrent comme du "code déjà fonctionnel" ne semble pas très agréable.

Mais il existe d'autres problèmes qui rendent les développeurs moins attentifs aux besoins de leurs testeurs. Premièrement, ils croient (à cause de ce que les organisations leur enseignent) que lorsqu'ils poussent leur code, cela devient le travail de quelqu'un d'autre. Ils ne sont pas conscients des efforts que les testeurs doivent déployer pour effectuer les tests. En fait, plusieurs fois, ils ne sont même pas au courant des plans de test, des ressources et parfois même des résultats (en dehors des bugs).

Donc la distance dans le temps, les connaissances, la réflexion - tout cela rend la discussion entre développeurs et testeurs peu efficace - notamment en termes de testabilité. Arriver en retard avec les demandes est trop tardif.

Des modèles de code qui conduisent à une meilleure testabilité

Il existe de nombreux modèles de code et anti-patterns que nous savons être bons (et mauvais) pour les développeurs. Habituellement, nous les considérons en termes de maintenabilité. Mais ils ont également un impact sur la testabilité.

Commençons par un simple. Disons que nous avons un service qui appelle une base de données. Maintenant, si les propriétés de la base de données sont hard-codées dans le code, chaque développeur vous dira que c'est une mauvaise chose, car vous ne pouvez pas remplacer la base de données par un équivalent. Dans un scénario de test, nous pourrions vouloir appeler une base de données fictive ou locale, et le codage en dur d'une connexion aura un impact sur notre capacité à exécuter le code complètement ou à en appeler un autre. Dans ce que nous appelons une architecture pluggable, c'est facile à faire, mais le code doit être écrit comme ça en premier lieu. C'est une victoire pour les testeurs et les développeurs. En fait, de nombreuses pratiques et patternss de code clean améliorent à la fois la maintenabilité et la testabilité du code.

Voyons maintenant un autre aspect de la pluggabilité. Notre service appelle désormais trois autres services et deux bases de données. Mais nous ne sommes pas intéressés à vérifier l'ensemble de l'intégration. Notre test actuel s'intéresse à n'appeler que la première base de données. Disons que nos développeurs ont appris de leur erreur précédente et que les composants sont entièrement pluggables.

Si vous utilisez le framework Spring de Java, par exemple, pour injecter tous les composants, vous devrez fournir des mocks ou autres pour exécuter les tests. Mais pas seulement pour la base de données qui nous intéresse - pour chaque bean, nous devrons fournir une doublure. Certains seraient faciles, et certains seraient difficiles à configurer. Et encore une fois - ce sont les composants qui ne présentent pas d'intérêt pour le scénario spécifique - nous en avons besoin juste pour faire le test.

Dans ces exemples (et il y en a beaucoup d'autres), les décisions de conception et de codage prises par le développeur ont un impact sur la possibilité d'exécuter le code de manière testable, ou sur la capacité d'écrire un test facilement. En concevant un code fortement couplé, la testabilité se dégrade. Et en codant en dur les propriétés de la base de données, encore une fois - une décision de conception par le programmeur - la testabilité peut être éliminée. Le développeur aurait pu opter pour une meilleure modularisation et pluggabilité, pour de meilleures options de testabilité. N'oubliez pas que vous pouvez avoir des options de conception presque infinies. Mais vous devez choisir ceux qui profitent à la qualité et à la maintenabilité.

Si le code n'est pas hautement testable, cela signifie qu'un code de test supplémentaire, des efforts et des franchissements d'obstacles seront nécessaires pour que les tests s'exécutent. Si, par exemple, la conception nécessite un utilisateur authentifié pour tester les scénarios, nous devrons configurer un utilisateur pour chaque scénario, configurer une authentification en deux étapes et la supprimer après cela - beaucoup de tracas juste pour tester comment une page se comporte. En revanche, si la conception permet de « débrancher » (ou court-circuiter) le processus d'authentification, les tests automatisés peuvent être plus faciles à écrire. Souvent, nous n'avons pas le temps pour cet effort supplémentaire, et ces scénarios de test ne sont pas exécutés ou ne sont pas prioritaires.

Et c'est dommage. En tant que testeurs, nous devons fournir les informations les plus complètes aux parties prenantes. Si nous n'avons pas la capacité d'exécuter des scénarios importants, ou s'ils prennent trop de temps à construire ou sont fragiles, nous ne pourrons pas le faire.

Dans les ateliers d'automatisation des tests que j'anime, je discute des modèles de code que les testeurs peuvent consulter et dire : « Cela me coûtera du temps plus tard ; nous ferions mieux de changer cela maintenant ». De nos jours, de plus en plus de testeurs maîtrisent le code, et j'encourage ce que nous appelons encore les « testeurs manuels » à apprendre le langage de programmation dans lequel leur produit est écrit. Mon expérience me dit que lorsque les testeurs parlent avec les développeurs, avec une compréhension de leur code, le résultat est une amélioration en testabilité.

Le plus simple que j'enseigne est quand "new" est utilisé au lieu d'injecter une dépendance. Si vous savez que c'est une dépendance « lourde », vous feriez mieux de la changer maintenant. Oui, cela a un coût, mais lorsque vous le maîtrisez, il est généralement faible. Il peut y avoir un risque ici. En modifiant le code (sans tests, puisque nous le faisons pour une meilleure testabilité), nous pouvons casser quelque chose. Examiner les modifications avant et après les avoir apportées peut atténuer le risque. Mais avoir un testeur pour discuter des risques améliore d'autres aspects de la testabilité.

Comme dernier exemple, voici une code smell symptomatique. Dans les code smells, nous avons des « god methods » et des « god classes » pour dire aux développeurs que le code est complexe et trop gros. Il existe une relation inverse entre le gros code complexe et son degré de testabilité. À chaque fois, les développeurs ont besoin de quelqu'un pour le leur faire remarquer. S'ils écrivent leurs propres tests, ils le découvrent très rapidement et les modifient. Malheureusement, ce n'est pas toujours le cas.

Apporter des modifications au code pour la testabilité

Il y a beaucoup de points communs entre les pratiques de clean code et la testabilité. L'architecture pluggable est une bonne pratique à la fois pour l'extensibilité (nous pouvons remplacer des éléments sans nouvelle version) et la testabilité (nous pouvons brancher une base de données fictive). C'est donc bon pour le développeur et le testeur.

Il y a un changement de code, également pour la testabilité, dans le cadre du développement, et il y a un changement « après développement » (ce n'est que notre perception, puisque le code est presque toujours en développement). Le point de vue du développeur, qu'il s'agisse d'un changement « utile » ou non, et parfois le coût (par exemple, supprimer le mot-clé Java « final » rendant la classe extensible) peut ne pas sembler si élevé ou risqué.

Voici une autre idée de la façon de présenter la suggestion : nous ne modifions pas le code pour le bien du testeur. Apporter des modifications conduit à un produit qui sera testé de manière plus approfondie, et nous en saurons donc plus sur ce que nous publions.

Après tout, nous pouvons toujours convenir que le code n'est pas parfait. Si on regarde, on y trouve souvent des bugs. Alors pourquoi ne pas apporter les changements qui conduisent finalement à une meilleure qualité ?

Les avantages sont infinis

Le principal avantage est la discussion entre les développeurs et les testeurs. Je me souviens il y a longtemps, en tant que chef d'équipe inexpérimenté, lorsque mon projet s'effondrait et que je ne savais pas quoi faire. Ce qui a sauvé le projet, c'est de mettre mon testeur et mon développeur sur le même ordinateur. Elle ne savait pas coder, il ne savait pas comment elle testait. Quand ils ont commencé à parler, la magie s'est produite.

Maintenant, imaginez comment cela peut fonctionner pour vous. Les discussions sur le code complexe et les systèmes qui changent tout le temps feront progresser la qualité, simplement en ayant ces conversations.

Mais ensuite, au niveau technique, nous parlons de la capacité de mieux tester le système et de fournir ces informations d'une manière qui se traduit aujourd'hui par "nous n'avons pas eu le temps de tester". Et comme je l'ai dit, la qualité du produit va de pair avec la qualité du code.

Ce que les responsables technologiques ou les architectes peuvent faire pour favoriser l'amélioration de la testabilité

Les discussions conjointes sont essentielles. Cela commence par des sessions de planification - à la fois pour la conception et l'architecture, et pour les tests. Les développeurs doivent savoir comment les tests seront effectués et les testeurs doivent savoir comment le code sera écrit. Un avantage supplémentaire est qu'ils peuvent signaler les risques assez tôt. Si les changements se situent dans un certain domaine, ils sauront ce qu'ils doivent tester d'autre. Si la zone est buguée, ils peuvent demander aux développeurs de mettre plus de tests unitaires autour.

Dans les rétrospectives, discutez de ce qui est « difficile » ou « facile » à tester. Définissez cela et explorez pourquoi. Nous pouvons apprendre les choses similaires que nous devrons continuer à faire, pour la prochaine fois.

Les sessions et discussions conjointes sont la base d'une communication efficace, mais profitent également à l'objectif d'un produit de qualité et maintenable.

A propos de l'auteur

Gil Zilberfeld (TestinGil) est un consultant en tests logiciels agiles avec plus de vingt ans d'expérience dans le développement et les tests. Il est l'auteur de "Everyday Unit Testing" et "Everyday Spring Testing". Il intervient régulièrement dans des conférences internationales. Gil Zilberfeld animera l'atelier "Make it public ! And other testability improvements" sur la testabilité du code à l'Agile Testing Days 2021. La conférence se tiendra du 15 au 18 novembre à Potsdam, en Allemagne.

Traduit avec www.DeepL.com/Translator (version gratuite)

 

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Votre profil est-il à jour? Merci de prendre un instant pour vérifier.

Note: en cas de modification de votre adresse email, une validation sera envoyée.

Nom de votre entreprise:
Rôle dans votre entreprise:
Taille de votre entreprise:
Pays/Zone:
État/Province/Région:
Vous allez recevoir un email pour confirmer la nouvelle adresse email. Ce pop-up va se fermer de lui-même dans quelques instants.