Aide:Tests unitaires
Cette page décrit comment utiliser des tests unitaires pour tester la robustesse des différents modules Lua du Wiktionnaire.
Pour les conventions de codage, se référer à la page dédiée.
Il est fortement recommandé de factoriser le code en petites fonctions réalisant une action précise et bien définie, car on peut alors plus facilement en tester le comportement.
Comment créer des tests unitaires
Considérons une page de module à tester, par exemple Module:paramètres. Pour créer des tests unitaires, on a besoin de créer deux pages :
- Module:données Unicode/testcases : c’est la que le code des tests est écrit.
- Module:données Unicode/testcases/Documentation : cette page affiche les résultats des tests unitaires. Comme il s’agit de la page de documentation, elle s’affiche en fait directement dans la page du code testcases.
En conditions réelles il faudra, bien entendu, remplacer paramètres par le nom du module à tester.
Page des résultats
Le contenu de cette page est simple, elle ne sert qu’à invoquer les tests et afficher les résultats. Par exemple dans notre cas :
Page du code des tests
Cette page contient l’ensemble des tests à réaliser. Elle doit être le plus complet possible.
Elle doit invoquer deux modules à la base : le module contenant ce qu’il faut pour effectuer les tests (Module:UnitTests) et le module à tester (ici Module:données Unicode).
Ensuite il faut écrire au moins une fonction par fonctionnalité dont le nom commence par test et la déclarer auprès du module tests chargé.
Tests du fonctionnement normal
Dans le cas de notre exemple, on veut tester le fonctionnement de la fonction getScriptForChar du module données Unicode, on appellera donc le test tests:testGetScriptForChar.
La fonction doit ensuite contenir des tests d’égalité ou d’erreurs, qui sont autant de cas d’usage de la fonction à tester. Dans l’exemple ci-dessous, on vérifie que la fonction renvoie bien le script « Latin » pour le caractère « A ».
La fonction de test de base est self:equals("Nom du test", valeur1, valeur2). Le test réussi uniquement si les deux valeurs (valeur1 et valeur2) sont égales. On va donc l’utiliser pour tester que le code du script retourné par la fonction est le bon.
À ce stade on a donc le code suivant :
local tests = require("Module:UnitTests")
local m_unicode = require("Module:données Unicode")
-- Tests --
function tests:testGetScriptForChar()
self:equals("Caractère", m_unicode.getScriptForChar("A").code, "Latin")
end
Notez le commentaire juste au-dessus de la fonction de test, il sert à indiquer le début de la section contenant les fonctions de test du fonctionnement normal et est obligatoire.
Test d’erreur
On veut maintenant vérifier que la fonction getScriptForChar lance la bonne erreur lorsqu’on lui passe aucun caractère ou plus d’un.
On va pour cela utiliser la fonction expect_error("Nom du test", fonction, paramètres, "Erreur attendue"). Le test réussi uniquement si la fonction fonction lance l’erreur spécifiée par le dernier paramètre. Le troisième paramètre est une table contenant les arguments à passer à la fonction.
À ce stade on a donc le code suivant :
local tests = require("Module:UnitTests")
local m_unicode = require("Module:données Unicode")
-- Tests --
function tests:testGetScriptForChar()
self:equals("Caractère", m_unicode.getScriptForChar("A").code, "Latin")
end
-- Error tests --
function tests:testGetScriptForInvalidChar()
self:expect_error("Chaine vide", m_unicode.getScriptForChar, { "" }, "Un seul caractère attendu, 0 donnés")
self:expect_error("Trop de caractères", m_unicode.getScriptForChar, { "AA" }, "Un seul caractère attendu, 2 donnés")
end
Notez la présence d’un deuxième commentaire. À l’instar de celui décrit dans la section précédente, il sert à introduire la section des fonctions de test d’erreurs. Il est lui aussi obligatoire.
Désactivation de tests
Pour désactiver un ou plusieurs tests, il faut appeler la fonction ignore(). Une fois la fonction appelée, tous les tests de la fonction de test dans laquelle l’appel a été fait seront ignorés. Ils seront quand même exécutés (limitation technique) mais leur résultat ne sera pas pris en compte.
La désactivation des tests doit rester exceptionnelle, si un test ne passe pas, il faut corriger le problème, pas l’ignorer. Elle peut cependant être utile dans le cas où de nombreux tests ont été écrits pour des fonctionnalités non encore implémentées, afin d’éviter du bruit inutile. Ils devront alors être réactivés dès que le travail d’implémentation de la fonctionnalité en question aura débuté.
Conclusion
Une fois ces deux pages créées, vérifiez que le code appelé n’a pas d’erreurs. Si le module testé a des erreurs, vous pouvez le corriger en utilisant la page de test (ici Module:données Unicode/testcases/Documentation) comme « Aperçu de la page avec ce modèle ».
Développement guidé par les tests
Il est fortement recommandé de créer les pages de test au plus tôt dans le développement d’un module pour pouvoir s’appuyer dessus tout au long du développement.
Toute modification du module y ajoutant de nouvelles fonctionnalités doit s’accompagner de tests correspondants.
Il est important de toujours vérifier la page de test avant toute modification, même mineure.
