Chapitre 4. Architecture de test

Table des matières
Introduction
Comment un test est-il réalisé ?
Un test de base
Comment écrire du code Scheme
Un cas de test pour le module fixed.so
Un cas de test pour le module consecutive.so

Introduction

L'architecture de test de Tablix fournit les moyens d'écritre des tests automatisés simples pour vérifier si un module et/ou le noyau fonctionne(nt) comme attendu. L'architecture est composée d'un module d'exportation spécial (export_ttf.so) et d'un programme utilitaire (tablix2_test). Vous pouvez les trouver tous les deux dans le sous-répertoire ttf/ de l'arbre des sources de Tablix.

Chaque cas de test automatisé vérifie généralement une seule fonction d'un module et est enregistré dans un seul fichier avec la syntaxe XML de configuration standard de Tablix et un bloc de commentaire spécial XML. Ce bloc contient un court programme écrit en Scheme (ndr: prononcé 'skim'). Le programme est ensuite utilisé pour vérifier l'emploi du temps généré par Tablix.

Note: Les tests pour tous les modules qui sont inclus dans la distribution de Tablix sont enregistrés dans le sous-répértoire ttf/tests/ . La plupart des modules sont suffisament compliqués pour qu'ils requiert plus d'un seul cas de test. Les fichiers de tests sont nommés nomdumodule-1.xml, nomdumodule-2.xml, nomdumodule-3.xml, etc...

Note: Le code en Scheme dans le cas de test joue un rôle similaire à la fonction d'ajustage dans le code du module. La différence majeure est que la fonction d'ajustage retourne un entier (au plus il est important, au plus il y a d'erreurs) tandis que le code Scheme retourne retourne un booléen (true si le test réussit, et false dans le cas contraire).

Vous pouvez vous demander pourquoi un langage aussi obscure que Scheme a été utilisé pour ce test. Deux raisons pour ce choix :
L'interpréteur TinyScheme fait seulement 4500 lignes de code, et est très simple à embarquer et à entendre. Il est sûr s'il est utilisé comme décrit et est disponible sous licence BSD.
Le but du test serait vicié si un programmeur pouvait copier-coller le code du module pour le test. Un langage de programmation avec une syntaxe complètement différente du C oblige l'auteur à réimplémenter l'algorithme d'une manière différente. Cela minimise les chances que deux implémentations (le module et le test) aient les mêmes erreurs.