Comment les tests de logiciels peuvent contribuer à la communication

Les tests de logiciels peuvent améliorer la communication et faire gagner du temps (et de la frustration). De mauvais tests peuvent avoir l'effet inverse. Dans cet article, nous allons étudier un exemple concret de la manière dont les mauvais tests sont nuisibles et dont les bons tests transmettent les bonnes informations.

Une histoire autour d'un titre

En Vividnous devions ajouter un titre à notre bouton. Ce n'est pas que le bouton n'en ait pas. Vivid est une bibliothèque basée sur des composants web, et à l'intérieur de notre élément button, il y a un bouton natif caché sous le Shadow DOM.

Ce bouton natif ne recevait pas le titre de son parent, ce qui n'était pas bon pour l'accessibilité de notre site web (sur la base de a11y ).

La tâche était donc assez simple. Obtenir un titre de l'hôte (l'élément personnalisé) et le refléter sur le bouton interne. C'est ainsi que cela se passe :

Nous utiliserons cet exemple et suivrons son chemin de validation pour comprendre et apprendre comment éviter des erreurs de test simples.

Leçon n° 1 : le changement d'interface est un signal d'alarme

Le premier commit de cette Pull Request a modifié l'interface. Voici le changement dans le test :

Les tests ont donc échoué. Vous pouvez voir que le test est passé de toBeFalsy à "être égal à une chaîne vide". Qu'est-ce qui ne va pas ?

Il y a trois erreurs dans cette affaire :

• toBeFalsy peut être plusieurs choses (chaîne vide, null, undefined, NaN, 0 et false), mais contrairement à une chaîne vide, elle n'est pas illimitée.

• L'interface n'a pas été suffisamment documentée, car toBeFalsy est trop large.

• L'interface a été remplacée par '' dans le test pour une raison quelconque. Quelle en est la raison ? S'agit-il d'une rupture ?

Ici, l'intrigue se corse. Ces deux erreurs ne sont que les amuse-gueules d'une perte de 24 heures de développement. Passons au plat de résistance.

Comment de mauvais tests conduisent à un mauvais code

Alors que j'essayais d'aider à résoudre le problème de l'échec du test, j'étais sur le chemin du retour de vacances.

J'ai regardé le code de test en utilisant mon téléphone et j'ai vu que l'interface documentée impliquait que la valeur du titre était censée être une chaîne vide.

"Bien sûr qu'il échoue ! La valeur initiale n'est pas une chaîne vide. Il suffit de la définir comme une chaîne vide, et cela fonctionnera."

Le changement est assez simple. Il suffit de définir la valeur dans le constructeur, et le test passera :

Cette correction a aggravé le problème que nous avions constaté lors de la première erreur. Nous avons non seulement modifié la documentation, mais aussi l'interface elle-même. Oui, les tests ont réussi, mais s'agissait-il du bon test ? Et comment une chose aussi simple a-t-elle pu nous coûter 24 heures de travail ? Venons-en à la deuxième erreur.

Erreur n°2 : Vous ne passerez pas (pour la bonne raison)

Le changement d'interface n'était que la première étape. Il y avait une véritable logique à mettre en œuvre, n'est-ce pas ? Voici le test pour la prochaine implémentation :

La première chose qui apparaît est la description du test. La faute de frappe (il manque le set après le not) est l'erreur la plus visible, mais il y a autre chose.

La description est rédigée sous forme négative. En science, on ne peut pas prouver que quelque chose n'existe pas. Comme les logiciels relèvent de l'informatique, nous pouvons les considérer de la même manière. Ne me dites pas ce qu'il ne doit pas faire - dites-moi ce qu'il doit faire.

Deux choses encore pires que la description se trouvent dans le code de test lui-même. Prenez une minute pour voir si vous les trouvez.

...

...

La minute est écoulée. Avez-vous trouvé une ou deux autres erreurs ?

Mauvaise raison n° 1 : tester la mauvaise chose

J'ai mentionné au début que notre mission était de définir le titre du bouton interne. Ce test ne décrit pas ce scénario.

Voyez-vous que le test est effectué sur l'élément, et non sur le bouton interne ? Lorsque j'ai lu le test, j'ai supposé que l'auteur voulait que le titre apparaisse sur l'élément. C'est ce que dit la documentation. Et c'est ce que j'attends du composant.

Mauvaise raison #2 : Les attentes ne correspondent pas à la description

Une autre chose est que l'attente dans ce test est d'avoir un titre avec une chaîne vide. Ce que nous voulons obtenir est totalement différent : nous voulons supprimer l'attribut title dans un tel cas.

12 heures se sont écoulées, et je suis rentré chez moi après mes vacances, réfléchissant à la manière d'implémenter le code pour se conformer à la spécification donnée.

Quelques messages sur Slack ont confirmé mes soupçons - l'attribut title devrait être supprimé lorsque le titre est faux. Je n'ai pas douté une minute que le titre ne devait pas être défini sur l'élément.

J'ai modifié un peu le test pour m'assurer que nous sommes sur la bonne voie :

t

On s'attend maintenant à ce que l'attribut soit effectivement supprimé.

Pour qu'il passe, j'ai dû modifier quelques éléments dans le modèle et la classe du composant. Dans la classe, j'ai dû remplacer l'attribut title (notre élément Class étend un autre élément de base Class). J'ai également dû mettre en place un convertisseur qui définit la valeur à null dans le modèle si la valeur est fausse, mais qui la laisse comme une chaîne de caractères si elle est modifiée depuis la vue elle-même :

Tout a fonctionné comme prévu. J'ai poussé et je m'attendais à ce que l'auteur des relations publiques me félicite de lui avoir sauvé la mise. Ou... non ?

La communication est essentielle

Le message Slack attendu est arrivé quelques heures plus tard. Le message lui-même était moins attendu :

Attendez, WAT ?!?

C'est ainsi qu'a commencé une nouvelle correspondance sur Slack. Elle a été courte, mais en fin de compte, c'est ce que j'ai retenu :

J'ai été choqué lorsqu'il a été révélé que le problème se situait au niveau du bouton interne.

Comme prévu, la correction a été minime. J'ai dû effectuer le test à la fois sur l'élément et sur le bouton interne (nous appelons ces éléments des "éléments de contrôle") :

Maintenant que nous avons mis en place un test, nous pouvons également nous assurer que notre valeur initiale sera plus spécifique et conforme à la spécification HTML (null) :

Cette simple réparation nous a pris 24 heures (oui, je sais que j'étais en vacances la moitié du temps, mais les excuses sont pour les faibles 😉 ). Elle aurait pu être sauvée avec de meilleurs tests ou de meilleures compétences en communication de ma part.

Conclusion

Rédiger de bons tests

Les tests sont censés échouer lorsque votre code ne fait pas ce qu'il est censé faire. Les tests sont également censés être une description directe du fonctionnement de votre code. Si le test indique qu'un titre doit figurer sur l'élément, il s'agit des instructions destinées à l'exécutant.

L'interface est également protégée par des tests. Si le test ne protège pas l'interface correctement ou de manière assez stricte (comme dans le cas de l'option toBeFalsy au lieu de toBeNull ici), nous ne savons pas vraiment à quoi nous attendre en tant que développeurs et consommateurs de l'interface. Vous pouvez en savoir plus sur l'importance des tests d'interface dans mon article, Une histoire d'implémentation et de détails.

Des tests d'écriture pour communiquer

Il est important d'avoir de bonnes compétences en matière de communication. Tout le monde ne les possède pas. Surtout dans les environnements de travail à distance. Si nous avions codé ensemble en personne, cela n'aurait peut-être pas pris autant de temps. Notre équipe travaille à distance (une équipe internationale) et la communication est généralement "asynchrone", ce qui signifie qu'il y a généralement un délai de réponse.

Rédiger les tests correctement, avec une description claire et une logique qui décrit comment les choses doivent se dérouler, permet d'atténuer ces erreurs de communication au sein de l'équipe.

Venez rejoindre la conversation sur notre Communauté Vonage Slack ou envoyez-nous un message sur X, anciennement connu sous le nom de Twitter.