J'ai passé les dernières semaines sur des systèmes de tests automatiques. Pour des programmes de mise à jour automatique et autres menus pour système embarqué. Ma première année en entreprise m'avait convaincu qu'il y avait un manque criant de tests automatiques dans mes programmes DS. Cet exercice-ci m'aura permis de trouver comment y remédier: je n'ai qu'à trancher correctement dans le code de telle sorte que les entrées/sorties puissent provenir du cas de test. Et peu importe que la DS n'ait pas beaucoup de ressources: les tests peuvent parfaitement s'exécuter sur une version du code compilée nativement pour linux et tourner là-dessus.
But over those last week, I started slicing direct-video programs in layers so that all user interactions could be emulated by file I/O (possibly driven by the test program). That 'test' version still has the same state machine, but I can capture its behaviour and scrutinize it. Why couldn't I do the same with C++ code of libgeds / SEDS / AnimEDS / LEDS ? It's mostly free of any architecture-dependent instructions (at machine code level, I mean) as soon as you realize you can have those DS registers mapped anywhere you like through twisted headers.
Wait and see ...
Sunday, July 12, 2015
Systematic testing vs. guru meditation
Tags: guru meditation, unit test
Subscribe to:
Post Comments (Atom)
1 comment:
Différence fondamentale entre le "testing" et le "auto-testing": mon collègue vient de me transmettre un bloc de code en affirmant "j'ai testé, ça marche". Fort bien. Et moi ? Quels tests dois-je faire pour m'assurer que ça marche ? Comment vérifier si "ça marche" toujours après l'une ou l'autre modification ?
Quand les tests sont automatisés via des scripts, ce genre de question ne se pose pas : "ça marche" == "le script s'est exécuté avec succès". Après, bien sûr, il est possible que le script ne couvre pas suffisamment de cas ou les couvre mal, mais au moins, on peut s'en rendre compte en lisant le script.
Post a Comment