Pourquoi les développeurs n’écrivent-ils pas plus de tests ?

D’une manière générale, les tests automatisés ont tendance à améliorer la fiabilité, la qualité et la maintenabilité des logiciels.

« Si vous avez mis en place des tests pour une fonctionnalité, vous saurez alors si un changement futur casse quelque chose », m’a dit Adam Gordon Bell de Earthly. Il a ajouté que les tests servent de forme dynamique de documentation : « Il est souvent plus facile de comprendre ce que fait quelque chose en lisant les tests qu’en lisant la mise en œuvre réelle. »

Cela dit, écrire des tests prend du temps et de nombreux développeurs ne prennent pas (ou ne peuvent pas) prendre le temps de les écrire. Au fur et à mesure que la base de code grandit et que la couverture des tests continue de diminuer, ce problème s’accentue.

« La gestion pousse fréquemment un grand nombre de fonctionnalités et les tests glissent toujours vers le bas de la liste des priorités… une fois que vous avez une base de code suffisamment grande, vous pouvez passer un temps infini à écrire des tests, il peut donc être intimidant et difficile de savoir par où commencer.  » – Ken Ahrens, PDG de Speedscale

Si les délais sont serrés ou si les chefs d’équipe ne sont pas particulièrement engagés dans les tests, c’est souvent l’une des premières choses que les développeurs de logiciels sont obligés de sauter.

D’un autre côté, certains développeurs ne pensent tout simplement pas que les tests en valent la peine. « Ils pourraient penser: » c’est une très petite fonctionnalité, n’importe qui peut créer un test pour cela, mon temps devrait être utilisé pour quelque chose de plus important. «  » m’a dit Mudit Singh de LambdaTest.

J’ai vu cette attitude selon laquelle les tests sont « en dessous » des développeurs dans des environnements d’entreprise où des équipes d’assurance qualité dédiées peuvent être responsables de la majeure partie des tests, mais cela peut se produire n’importe où. J’ai déjà dirigé un développeur senior dans une startup qui m’a encouragé à embaucher des développeurs juniors juste pour écrire des tests pour lui.

Ainsi, vous pourriez penser que la réponse est simple. Donnez aux développeurs plus de temps pour écrire des tests et en faire une partie de leur travail, n’est-ce pas ?

En vérité, il existe des limites légitimes aux tests automatisés. Comme beaucoup de sujets compliqués dans le développement de logiciels, le choix de tester ou non consiste à comprendre les compromis.

« Rédiger des tests automatisés peut vous assurer que certaines parties de votre application fonctionnent comme prévu », m’a dit Aidan Cunniff, PDG d’Optic, « mais le compromis est que vous avez investi beaucoup de temps à « stabiliser » et à rendre « fiable » cette partie de votre système.

J’ai également vu cela dans mon expérience dans les startups. Une fois, j’ai passé trois semaines à créer une nouvelle fonctionnalité, à écrire des tests et à résoudre des revues de code pour me faire dire que l’équipe commerciale avait changé d’avis et que la fonctionnalité allait être supprimée lors du prochain sprint.

Bien que les tests aient pu améliorer ma nouvelle fonctionnalité et la maintenir plus facilement, ils étaient techniquement une perte de temps pour l’entreprise car la fonctionnalité n’était pas vraiment ce dont nous avions besoin. Nous n’avons pas investi suffisamment de temps pour comprendre le problème et faire un plan avant de commencer à écrire du code.

« Imaginez qu’un groupe de gars de la construction et l’architecte se rencontrent dans un terrain vague avec le client et une grosse pile de bois. Puis ériger une maison de façon spontanée. Lorsque le client regarde avec méfiance la maison finie et se plaint que le toit n’a pas l’air très sûr, l’entrepreneur répond : « Ne vous inquiétez pas, nous allons simplement attendre qu’il pleuve et ensuite réparer les fuites. »… Aucune autre profession ne construit produits de qualité non contrôlée s’appuie ensuite sur des tests (et la réparation des défauts) pour améliorer la qualité du produit. – Mythes sur les tests de logiciels

Enfin, certaines formes de tests sont particulièrement difficiles à mettre en œuvre car elles nécessitent que votre code soit écrit d’une manière spécifique. Il s’agit d’une plainte courante concernant les tests unitaires.

D’une part, les tests unitaires obligent les développeurs à structurer leur code de manière « testable », mais d’autre part, ces tests unitaires vous indiquent rarement si l’application finale apporte de la valeur aux utilisateurs.

« Dans la plupart des entreprises, les seuls tests qui ont une valeur commerciale sont ceux qui découlent des exigences de l’entreprise. La plupart des tests unitaires sont dérivés des fantasmes des programmeurs sur la façon dont la fonction devrait fonctionner… Ceux-ci n’ont aucune valeur prouvable. – Pourquoi la plupart des tests unitaires sont des déchets, James O. Coplien

Si vous travaillez dans une base de code héritée qui n’avait pas de couverture de test unitaire avant de commencer, il est presque impossible de les ajouter rétroactivement. Ainsi, la plupart des développeurs se tournent vers l’intégration ou les tests de bout en bout.

Ces tests fonctionnels peuvent être utiles, mais ils sont également problématiques. Toute application importante aura des dizaines de fonctionnalités et de branches logiques, il devient donc presque impossible de suivre tout le comportement prévu. Comme le souligne JB Rainsberger dans son essai, Les tests intégrés sont une arnaque, une application Web de taille moyenne avec 20 pages peut nécessiter 10 000 à 1 000 000 de tests juste pour couvrir toutes les histoires d’utilisateurs.

« Je pense que les tests unitaires et en particulier le développement piloté par les tests ont été survendus par ses partisans comme remède à tous les problèmes… Mais les tests, lorsqu’ils sont bien faits, sont très précieux. Écrivez des tests pour le futur vous, qui essayerez de comprendre ce que cette méthode fait à l’avenir. Donnez-vous la confiance nécessaire pour effectuer les changements dont vous avez besoin. – Adam Gordon Bell, Terrestre

Bien que les tests ne soient pas une panacée, ils sont légitimement utiles lorsqu’ils sont appliqués de manière appropriée au logiciel en question. Dans presque tous les cas, les tests sont un net positif pour les développeurs, même s’ils ont des limites. La chose importante que les équipes de développement doivent faire est d’être intentionnelle quant à la manière et à ce qu’elles testent.

« Délibérer sur l’endroit où vous investissez vos efforts de test est le meilleur moyen d’équilibrer votre investissement avec la valeur qu’il offre », m’a dit Aidan Cunniffe. Il peut être raisonnable de sauter les tests sur votre première version alpha d’une nouvelle fonctionnalité, mais « quand cette fonctionnalité devient l’épine dorsale de 3 autres fonctionnalités, il est temps de commencer les tests ».

Personnellement, je suis d’avis qu’une approche mixte est la meilleure. Les tests unitaires sont utiles pour couvrir rapidement de nombreux cas infimes, les tests d’intégration garantissent que les pièces interagissent comme prévu et les tests de bout en bout fournissent une vérification finale du fonctionnement de l’interface utilisateur.

Il existe également de nouvelles variétés de tests émergents qui cherchent à atténuer certaines des lacunes de l’approche de test en couches que beaucoup d’entre nous adoptent. Par exemple, j’ai étudié un certain nombre d’outils de test low-code l’année dernière, et d’autres sont à l’horizon. Sushil Kumar, PDG de RelicX, a souligné que « la génération automatique de scripts de test à l’aide de tests basés sur l’IA/ML peut grandement contribuer à réduire la charge de travail des développeurs ».

Si vous êtes si loin dans le débat et que vous ne testez tout simplement pas parce que vous ne savez pas par où commencer, parlons de l’endroit où vous pouvez commencer.

L’endroit le plus simple pour commencer est généralement les tests unitaires. « Lorsque vous vous lancez dans les tests, déterminez quel framework de test unitaire votre équipe utilise et incluez un cas de test unitaire pour votre premier enregistrement de code », m’a dit Ken Ahrens de Speedscale. Continuer en expliquant que commencer petit mais faire des tests une habitude est la clé pour s’y tenir.

Ensuite, vous devez obtenir l’adhésion du reste de votre équipe et de la direction. Les développeurs doivent avoir le temps d’écrire des tests en sachant que cet investissement sera rentable à long terme.

« Soit tout le monde dans l’équipe écrit des tests, soit personne ne le fait, c’est vraiment une pratique culturelle, une impasse technique. Personne ne veut être la seule personne à le faire. – Aidan Cunniffe, Optique

Une façon de prouver à quel point les tests peuvent être utiles est de les utiliser pour empêcher les régressions. « Si quelque chose ne fonctionne pas », m’a dit Adam Gordon Bell, « écrivez un test pour le bon fonctionnement avant de le réparer. » Cela rendra les régressions futures moins probables et donnera confiance à votre équipe lors de la mise à jour de cette partie du code à l’avenir.

Les tests ont des limites et ils ne remplacent pas une excellente conception de système, mais les tests ont également leur place dans le développement de logiciels. Donner aux ingénieurs le temps de tester et transmettre la valeur des tests à votre équipe est un rôle important dans le leadership en ingénierie, et cela devient de plus en plus critique à mesure que le logiciel devient plus complexe.