Sunday, July 12, 2015

Systematic testing vs. guru meditation

I have a colleague at work who's the expert in buildbots and testbots. I'm very excited to know what he will think about the way I used overlayfs and fakechroot to emulate the install script of the self-upgrade system for the device we're launching. It is not my first try at testing systems -- I grew the habit of building test scripts for students' black-box programs for marking their assignments -- but it is clearly the first time I push it to the level where it is easier to know whether the program is correct than to rebuild it ^^"

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.

Less than a few weeks ago, I thought that unit testing and the like had no chance to be useful for my Nintedo DS programs, although it would clearly be welcome to avoid regression... But hey! Knock knock! We have 66MHz and 4MB. Do you really expect the emulator to run unit testing ?
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 ...

1 comment:

PypeBros said...

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.