Pyramide des tests

Albert Einstein

No amount of experimentation can ever prove me right; a single experiment can prove me wrong

La célèbre citation d’Albert Einstein est également valable pour le développement de logiciels, et si tous les tests passent, cela ne signifie pas que le programme est correct. En revanche, si un seul test échoue, alors le programme est prouvé faux. Ca ne signifie pas que les tests ne sont pas imortants et plus vous en écrivez, plus vous avez de chances de trouver les erreurs dans votre programme.

En ingénierie logicielle, les différents types de tests sont souvent représentés sous la forme d’une pyramide :

Unit tests (tests unitaires)

La base de la pyramide est constituée de “tests unitaires”. Ces tests sont plutôt courts et doivent s’exécuter automatiquement. Aucune interaction humaine ne doit être nécessaire pour les exécuter. Sur les systèmes embarqués, ils sont généralement exécutés sur le microcontrôleur lui-même. Si un test donné implique du matériel (par exemple, une LED ou un bouton poussoir), nous avons besoin d’équipement supplémentaire (par exemple, un voltmètre ou un ampèremètre connecté) pour exécuter le test de manière autonome.

Dans l’infrastructure de l’école, nous avons des “runners” connectés à des cibles qui permettent à Gitlab de faire tourner du code sur les microcontrôleurs eux-mêmes.

Integration tests (tests d’intégration)

Au milieu de la pyramide, nous trouvons les “tests d’intégration”. Ici, nous vérifions que les parties intéragissent correctement et que le programme se comporte comme prévu. Il est préférable d’également automatiser ces tests, mais cela n’est pas toujours possible.

User interface tests (tests d’interface utilisateur)

Le sommet de la pyramide est constitué de “tests d’interface utilisateur”. Ces tests sont plus complexes et sont souvent écrits sous la forme d’une liste de points à contrôller. Un humain passera en revue la “check-list” et sera invité à effectuer manuellement les tests. Il est préférable dque ce ne soit pas le développeur qui effectue les tests, car le développeur est souvent trop “prudent” et n’ose pas tester les limites de sa création.