Essai
Pourquoi des tests automatiques ?
Voici quelques-unes des nombreuses bonnes raisons pour lesquelles nous devrions avoir des tests automatisés :
Vous pouvez effectuer des mises à jour incrémentielles de votre code plus rapidement. ROS a des centaines de packages avec de nombreuses interdépendances, il peut donc être difficile d’anticiper les problèmes qu’un petit changement pourrait causer. Si votre modification réussit les tests unitaires, vous pouvez être plus sûr que vous n’avez pas introduit de problèmes - ou du moins que les problèmes ne sont pas de votre faute.
Vous pouvez refactoriser votre code avec plus de confiance. La réussite des tests unitaires vérifie que vous n’avez introduit aucun bogue lors de la refactorisation. Cela vous donne cette merveilleuse liberté de la peur du changement !
Cela conduit à un code mieux conçu. Les tests unitaires vous obligent à écrire votre code afin qu’il puisse être testé plus facilement. Cela signifie souvent que vos fonctions sous-jacentes et votre framework sont séparés, ce qui est l’un de nos objectifs de conception avec le code ROS.
Ils évitent les bugs récurrents (régressions de bugs). C’est une bonne pratique d’écrire un test unitaire pour chaque bogue que vous corrigez. En fait, écrivez le test unitaire avant de corriger le bogue. Cela vous aidera à reproduire précisément, voire de manière déterministe, le bug, et à comprendre beaucoup plus précisément quel est le problème. En conséquence, vous créerez également un meilleur correctif, que vous pourrez ensuite tester avec votre test de régression pour vérifier que le bogue est corrigé. De cette façon, le bogue ne sera pas accidentellement réintroduit si le code est modifié ultérieurement. Cela signifie également qu’il sera plus facile de convaincre l’examinateur du correctif que le problème est résolu et que la contribution est de haute qualité.
D’autres personnes peuvent travailler plus facilement sur votre code (une forme automatique de documentation). Il peut être difficile de déterminer si vous avez ou non cassé le code de quelqu’un d’autre lorsque vous apportez une modification. Les tests unitaires sont un outil permettant aux autres développeurs de valider leurs modifications. Les tests automatiques documentent vos décisions de codage et informent automatiquement les autres développeurs de leur violation. Ainsi, les tests deviennent une documentation pour votre code - une documentation qui n’a pas besoin d’être lue la plupart du temps, et lorsqu’elle doit être inspectée, le système de test indiquera précisément ce qu’il faut lire (quels tests échouent). En écrivant des tests automatiques, vous rendez les autres contributeurs plus rapides. Cela améliore l’ensemble du projet ROS.
Il est beaucoup plus facile de devenir contributeur de ROS si nous avons des tests unitaires automatisés. Il est très difficile pour les nouveaux développeurs externes de contribuer à vos composants. Lorsqu’ils apportent des modifications au code, ils le font souvent à l’aveugle, motivés par de nombreuses conjectures. En leur fournissant un harnais de tests automatisés, vous les aidez dans la tâche. Ils reçoivent un retour immédiat sur leurs modifications. Il devient plus facile de contribuer à un projet, et de nouveaux contributeurs de se joindre plus facilement. De plus, leurs premières contributions sont de meilleure qualité, ce qui diminue la charge de travail des mainteneurs. Un gagnant-gagnant!
Les tests automatiques simplifient la maintenance. En particulier pour les packages matures, qui changent plus lentement et doivent principalement être mis à jour avec de nouvelles dépendances, une suite de tests automatiques permet de déterminer très rapidement si le package fonctionne toujours. Il est ainsi beaucoup plus facile de décider si le package est toujours pris en charge ou non.
Les tests automatiques amplifient la valeur de l’intégration continue. Les tests de régression, ainsi que les tests d’exigences basés sur des scénarios normaux, contribuent à l’ensemble des tests automatisés pour votre composant. Votre composant est mieux testé par rapport à l’évolution des autres API dont il dépend (les serveurs CI vous diront mieux et plus précisément quels problèmes se développent dans votre code).
L’avantage le plus important de la rédaction de tests est peut-être que les tests font de vous un bon citoyen. Les tests influencent la qualité à long terme. C’est une pratique bien acceptée dans de nombreux projets open source. En écrivant des tests de régression, vous contribuez à la qualité à long terme de l’écosystème ROS.
Tout cela est-il gratuit ?
Bien sûr, il n’y a jamais de déjeuner gratuit. Pour bénéficier des avantages des tests, certains investissements sont nécessaires.
Vous devez développer un test, ce qui peut parfois être difficile ou coûteux. Parfois, cela peut aussi être non trivial, car le test doit être automatique. Les choses deviennent particulièrement délicates si vos tests doivent impliquer un matériel spécial (ils ne doivent pas : essayer d’utiliser la simulation, se moquer du matériel ou limiter le test à un problème logiciel plus petit) ou nécessiter un environnement externe, par exemple des opérateurs humains.
Les tests de régression et autres tests automatiques doivent être maintenus. Lorsque la conception du composant change, de nombreux tests deviennent invalides (par exemple, ils ne compilent plus ou lèvent des exceptions d’exécution liées à la conception de l’API). Ces tests échouent non seulement parce que la refonte a réintroduit des bogues, mais aussi parce qu’ils doivent être mis à jour avec la nouvelle conception. Occasionnellement, avec des remaniements plus importants, les anciens tests de régression doivent être abandonnés.
L’exécution de grands ensembles de tests peut prendre beaucoup de temps, ce qui peut augmenter les coûts du serveur d’intégration continue.