Etape 13 : Logiciel testeur
Si vous n’utilisez pas un Conseil de RAMBo cependant, vous devrez adapter le logiciel à votre Conseil d’administration. Récemment, le logiciel a été réécrit à partir de zéro pour permettre un port facile dans d’autres conseils. Notions de programmation Python est cependant requises.
Le nouveau design permet une approche plus modulaire où chaque test est représenté par un objet unique et chaque type de test est mis en œuvre dans sa propre classe. Quelques classes de base sont disponibles pour prendre en charge les fonctionnalités de base des cas test, mécanisme de journalisation et de tests de logique.
Les tests / module contient des classes de base et des modules de test. Les classes de base sont :
- Test unitaire : C’est la classe de base pour un scénario de test mis en place pour tester une fonctionnalité spécifique
- TestContext : C’est la classe de base pour le contexte donné aux épreuves, alors qu’ils sont en cours d’exécution
- TestRunner : C’est la classe de base de la classe runner qui s’exécutera tous les tests à la suite de tests.
Il y a quelques tests génériques, tels que le TestGPIO dans gpio.py et TestAnalog analog.py, qui eux-mêmes ont plus spécifique tester les classes qui dérivent d’eux comme TestMosfets et TestEndstops qui dérivent de TestGPIO et de TestThermistors, de TestVRefs et de TestSupplyRails qui dérivent de TestAnalog. Il y a aussi quelques tests spécifiques tels que le ProgramFirmware qui est un wrapper de test pour avrdude et TestMotors qui vont tester les moteurs pas à pas et vérifier que tout fonctionnent correctement.
Pour implémenter un nouveau test, vous devez dériver de la classe de test unitaire et substituez les méthodes _Tester et _verify . La méthode _test doit exécuter le test en utilisant tout ce qui est disponible dans l’objet de contexte (plus sur cela plus tard) alors que la méthode _verify doit définir le 'self.status' une valeur dans l’énumération TestStatus .
L’objet de contexte qui est passé aux méthodes _test et _verify est un objet qui dérive de TestContext, son but est de passer autour d’informations entre les tests qui peuvent être utilisés par les cas de test. Par exemple, l’interface pour accéder à l’ASE est disponible dans context.target alors que le contrôleur est disponible comme context.controller. En outre, la plupart des tests devra avoir accès à des domaines spécifiques de l' objet context.pinmapping.
Vous aurez besoin de dériver une classe de TestContext afin de fournir l’information requise pour les cas de test. Plus précisément, dans votre classe dérivée, vous devez instancier un objet self.pinmapping . Si vous avez besoin pour allumer/éteindre l’alimentation avant et après une série de tests par exemple, vous pouvez le faire en substituant les méthodes TestingStarted et TestingEnded .
Enfin, vous devez implémenter une classe nouvelle pour votre carte mère qui dérive de TestRunner. C’est simple, qu'il suffit de définir une variable de self.tests contenant une liste d’objets de test unitaire et de retourner le contexte que vous avez créé via la propriété context .
Vous pouvez alors créer votre objet TestRunner et appeler la méthode Run pour exécuter tous les tests, ou vous pouvez lui donner une liste de tests spécifiques à exécuter si vous le souhaitez.
Il y a beaucoup plus que l'on puisse dire concernant le logiciel, tels que _finally fatal, l’exige, les cas de test, ou comment faire pour configurer le système de journalisation pour utiliser une base de données ou comment obtenir l’aperçu de l’exécution de tests ou de désactiver des tests spécifiques, ce que chaque test état moyen, etc... Toutefois, le code source est relativement simple et bien documenté, et vous pouvez découvrir beaucoup de choses en lisant le code.
Je vous laisse avec une maquette d’un GUI potentiel pour le logiciel de test dans lequel le GUI peut être généré dynamiquement de n’importe quelle instance TestRunner et qui permet de contrôler chaque test à l’utilisateur.
