Les tests automatisés de logiciels embarqués sont une nécessité

Il existe une stratégie de développement typique que beaucoup de développeurs utilisent, je pense, pour déboguer et tester leur logiciel embarqué, à savoir : compiler, programmer, déboguer, tester sur place, ajuster puis répéter. J’ai moi-même utilisé ce processus pendant des années, après tout, cela semblait naturel et avait beaucoup de sens.

Malheureusement, ce type de stratégie de développement pose de nombreux problèmes, tels que la dépendance au matériel, la perte de temps à programmer du matériel, le temps passé à déboguer et à effectuer des contrôles ponctuels. Malheureusement, ces derniers sont souvent des tests manuels intensifs de «croisement des doigts». Dans le post d’aujourd’hui, je veux parler un peu d’un projet d’auto-amélioration sur lequel je travaille depuis plusieurs années pour améliorer la façon dont j’écris et teste mon propre logiciel embarqué.

À l’époque où j’étais ingénieur junior, je suis tombé sur un livre intéressant et intrigant qui avait été publié intitulé Test-Driven Development (TDD) pour Embedded C par James Grenning. La prémisse du livre était que TDD n’était pas seulement pour les développeurs de logiciels travaillant sur des serveurs et dans des applications Web, mais qu’il y avait beaucoup de valeur que les développeurs de logiciels embarqués pouvaient gagner en adoptant les principes de TDD. L’un des avantages, que j’ai trouvé irremplaçable dans mes propres activités de développement de logiciels, était l’utilisation d’un harnais de test automatisé.

Les harnais de test sont des outils assez connus et utilisés aujourd’hui, mais les développeurs embarqués semblent encore résister à leur utilisation (en fonction de leur expérience et des types d’entreprises pour lesquelles ils ont travaillé). Ils permettent à un développeur d’écrire une série de tests qui peuvent ensuite être exécutés sur son code pour détecter les défauts et vérifier que le code se comporte comme il s’y attend. Ce que j’aime le plus chez eux, c’est que je peux modifier mon code, puis réexécuter tous les tests précédents que j’ai créés pour découvrir si j’ai cassé quelque chose dans mon code. Si j’adhérais aux « anciennes pratiques », je vérifierais très probablement le code et j’aurais un bogue non trouvé en attente d’être découvert par un client ou un utilisateur.

Je travaillais récemment sur un projet et je voulais comparer à quel point la vérification ponctuelle fonctionnait en exécutant le code sur le matériel pour vérifier que le code fonctionnait par rapport à la construction d’une série de cas de test. J’ai écrit mon code, effectué les vérifications ponctuelles habituelles et constaté que mon code fonctionnait très bien. Je me sentais vraiment bien à ce sujet. Je l’avais écrit rapidement et j’y ai mis beaucoup de sueur. En fait, j’avais l’impression que c’était peut-être le meilleur et le plus robuste morceau de code que j’aie jamais écrit. La question, cependant, est la suivante : le harnais de test conviendrait-il ?

J’ai donc commencé à écrire des cas de test qui seraient intégrés dans cpputest, un harnais de test C/C++, pour voir ce qui se passerait. Tout d’abord, lors de ma vérification ponctuelle sur la cible embarquée, j’avais créé une vingtaine de cas de test. Lorsque j’ai construit mon harnais de test, j’ai découvert que j’avais environ 36 cas de test. J’ai également constaté que lorsque j’ai effectué mes tests, il n’y avait pas moins de cinq bugs à découvrir dans le module. Maintenant, ces bogues étaient des cas extrêmes et ils n’ont peut-être jamais été rencontrés sur le terrain, mais s’ils l’avaient été, ils auraient pu entraîner un comportement du système assez embarrassant.

La façon dont j’ai utilisé le harnais de test pour comparer les résultats à des vérifications ponctuelles n’est pas vraiment le bon processus pour quelqu’un qui s’intéresse au TDD. Dans TDD, le développeur écrit d’abord un scénario de test, puis il le fait échouer et écrit le code pour le faire passer. Mon expérience consistait simplement à boulonner un harnais de test et quelques cas de test sur un morceau de code existant. Les résultats, cependant, dans mon esprit, montrent qu’il y a plusieurs avantages importants à utiliser des tests automatisés avec un logiciel intégré, notamment :

• Création de tests qui continuent de vérifier l’intégrité du logiciel même lorsque de nouvelles fonctionnalités sont ajoutées
• Création de cas de test connus pour détecter réellement un défaut
• Forcer un développeur à penser aux tests et aux modes de défaillance tout au long du cycle de développement
• Améliorer la robustesse du code
• Permettre à un développeur d’abstraire et de découpler son code d’application du matériel sous-jacent

Il y a certainement de nombreux autres avantages, mais je vois souvent ces domaines négligés, et adopter une approche de type test plutôt TDD permet de générer de nombreux avantages non seulement pour les entreprises qui fabriquent des produits, mais aussi pour les utilisateurs finaux. Lorsque j’ai rencontré TDD pour la première fois, j’ai pensé que cela prenait trop de temps et ne pouvait vraiment pas aider les développeurs embarqués à écrire du code plus rapidement et de manière plus robuste. Je n’ai plus ce point de vue. En fait, lorsque je commence à écrire un morceau de code, la première chose que je configure est mon harnais de test car, sans lui, j’ai l’impression de tourner en rond et de développer trop lentement.