Tester Inkscape

Inkscape est un projet jeune, encore concentré sur l'ajout de fonctionnalités. Néanmoins, la stabilité d'Inkscape a régulièrement crû à chaque distribution.

La partie la plus importante du « test » est simplement l'utilisation normale d'Inkscape — confirmant qu'Inkscape a atteint son niveau de maturité, gère les ajouts et assure que l'application marche comme attendu.

Rapportez les bogues que vous constatez. Un rapport de bogue devrait inclure au moins une description étape par étape de la manière de déclencher le bogue et/ou un fichier d'expérimentation qui le provoque (le plus petit/concentré possible).

Utilisateurs

Le champ est largement ouvert. Nous sommes enthousiastes de recevoir des rapports de bogue et des demandes de fonctionnalité (sous la forme de rapports de bogue). Ces rapports ont souvent besoin d'être analysés, clarifiés et approfondis. N'importe qui peut y contribuer.

Le mieux serait toujours de fournir des patchs pour une partie de l'application qui ne fonctionne pas comme vous l'attendez — c'est la confirmation que le projet évolue. Notez que le test sérieux devrait être fait avec une version « instable », soit faite par vous-même (voyez Compiler Inkscape), soit une version téléchargée. Nous aimerions aussi entendre les secteurs dans lesquels nous ne sommes pas implantés contrairement aux applications similaires. Si vous avez des idées intéressantes concernant les défauts d'Inkscape, ou des plans pour son avenir, impliquez-vous dans le groupe des testeurs d'Inkscape.

Nous avons besoin de gens pour créer et mettre à jour la documentation, l'aide en ligne, les tutoriels et les captures d'écran. Noter les défauts à ces endroits est une forme de test parfaitement valide — nous ne voulons pas que des versions soient livrées avec une documentation obsolète.

Testeurs d'Inkscape

Section obsolète.

Une communauté de testeurs d'Inkscape s'est développée et possède sa propre liste de diffusion, et il est attendu qu'elle dirige tout le travail sur l'utilisabilité et les facteurs humains. Ce groupe devrait être votre premier point d'appel pour les zones suivantes :

• Tests de conformité
• Tests de régression d'Inkscape
• Tests d'interopérabilité
• Tests d'utilisabilité
• Tests de performance
• Conformité aux bonnes pratiques de l'IHM

Renseignez-vous également sur le cadriciel de test.

Tests de rendu

Section obsolète.

En plus de ce qui précède, Inkscape effectue des tests de rendu qui ne nécessite pas forcément de développeur pour être créés, exécutés et analysés. Les tests en question peuvent être trouvés sur SVN (voir ci-dessous). Nous donnons plus bas des informations sur la procédure pour exécuter et créer ces tests vous-même.

Consultez cette liste pour des résultats mis à jour.

Lancer des tests de rendu

En plus d'exécuter des tests unitaires bas niveau, Inkscape peut être testé à un niveau plus élevé (voir aussi Conformité à la suite de tests SVG). Actuellement (26/07/2008), il y a un outil de test du rendu (avec quelques cas de test) sur SVN qui peut être utilisé pour automatiser une partie des tests de rendu.

Pour lancer les tests de rendu :

• Si nécessaire, compilez tester.cpp avec `g++ -o tester tester.cpp` (il y a un .exe précompilé sur SVN pour les utilisateurs de Windows).
• Exécutez runtests.py. Si besoin, vous pouvez indiquer le chemin vers Inkscape et quelques autres paramètres (exécutez `runtests.py --help` pour savoir quelles options sont disponibles).

Notez que par défaut seule une comparaison binaire entre les fichiers de sortie et de référence est utilisée ; perceptualdiff (ou tout autre outil de comparaison qui retourne zéro en cas de succès et 1 en cas d'échec) peut être utilisé pour comparer les images (consultez les options de runtests.py). Notez que perceptualdiff (1.0.2) avait des problèmes avec la transparence, qui sont peut-être corrigés aujourd'hui, et si ce n'est pas le cas, il y a un patch dans son traqueur de patchs.

Pour sélectionner un sous-ensemble de tests à effectuer, spécifiez un ou plusieurs motifs (avec des métacaractères de style Unix) sur la ligne de commande. Chaque motif est interprété comme une spécification de préfixe. Par exemple, `runtests.py bugs` va sélectionner tous les tests dont le chemin relatif au répertoire avec les cas de tests commence par « bugs » (par exemple : « bugsy.svg » ou « bugs/bugXYZ.svg »).

Les résultats de test les plus courants sont :

• Pass (le fichier de sortie correspond à une référence de réussite)
• Fail (le fichier de sortie correspond à une référence d'échec)
• New (le fichier de sortie ne correspond à aucune référence)
• No references (il n'y avait aucune référence)

runtests.py place les fichiers de sortie dans un sous-répertoire « output » (au même niveau que les répertoires « testcases » et « references »).

Créer des tests de rendu

Placez simplement un fichier SVG dans le dossier « testcases » (des sous-répertoires peuvent être utilisés pour trier les tests).

Pour ajouter une référence de succès ou d'échec, placez-la à l'emplacement correspondant dans references/pass ou references/fail. Les références sont sélectionnées par préfixe, donc toute référence préfixée par le nom d'un fichier (sans son extension) est utilisée comme référence pour ce fichier.

Les références d'échec sont utilisées pour distinguer un résultat que l'on sait faux et un résultat qui est juste (peut-être très légèrement) différent du rendu correct. Si vous ne parvenez pas à créer une référence de succès, vous pouvez vous contenter de fournir une référence d'échec.

Il est également possible de créer un fichier SVG qui devrait produire une sortie identique à un cas de test mais qui utilise des méthodes plus simples (ou différentes). Cette pratique est suggérée dans le plan de test de conformité au SVG. Par exemple, si le fichier du cas de test s'appelle « testcases/basic/foo.svg », vous pouvez créer un fichier de « patch » appelé « testcases/basic/foo-patch.svg ». runtests.py utiliserait alors Inkscape pour créer un fichier de référence de succès avec ça (qui serait « references/pass/basic/foo-patch.svg ») et l'utiliserait comme une référence (notez qu'en général, cette référence ne devrait pas être envoyée sur le dépôt).

Développeurs

Rapport de construction

Il y a un rapport de construction d'Inkscape (« inkscape build report ») qui est régulièrement envoyé à la liste inkscape-tester (et périodiquement à la liste des développeurs, lorsque de nouveaux problèmes sont découverts) et qui fournit des avertissements dans le code.

• Smoketests
• Défauts dans le système de construction

Lancer des tests unitaires

Il y a maintenant des tests unitaires qui devraient être effectués avant la vérification. Ceux-ci peuvent mettre un certain temps à se terminer, et ne peuvent donc pas être obligatoires à chaque construction (développement piloté par les tests) ; néanmoins, tout le monde sur son honneur doit éviter de « casser la construction » en soumettant un code qui ne passe pas ces tests. Vous pouvez les lancer de cette manière :

• Sous Linux : Exécutez « make check » ; cela construira et exécutera les tests. Cela devrait aussi fonctionner sur Mac OS X.
• Sous Windows : Utilisez « buildtool check » (où buildtool est construit avec « g++ -O3 -o buildtool buildtool.cpp ») pour construire et exécuter les tests unitaires. Vous pouvez également utiliser dist-all-check pour tout construire ET lancer les tests unitaires.

Cxxtests générera deux (plus ou moins équivalents) fichiers résultants : un fichier XML et un fichier texte avec l'extension « log ». Sous Linux, ces fichiers sont situés dans <chemin-de-construction>/src.

Créer des tests unitaires

Inkscape utilise le cadriciel CxxTest. Pour améliorer, modifier ou étendre les tests unitaires, modifiez juste le fichier de test existant (…-test.h).

La manière la plus facile de créer un nouveau test dans un répertoire qui contient déjà des tests unitaires est simplement de copier l'un des fichiers de test existants, de le formater (y supprimer tout ce qui est spécifique et renommer la classe, les constructeurs, etc.) et d'ajouter des méthodes de test. Prenez le temps de regarder les différentes instructions ASSERT que CxxTest prend en charge ; les variantes TSM_ peuvent être particulièrement utiles par exemple lorsque vous souhaitez tester de nombreux cas différents. Important : pour que tout se construise correctement, vous devez faire ce qui suit :

• ajoutez le fichier au groupe de droite (déjà existant) dans la cible cxxtest dans build.xml ;
• ajoutez le fichier à la variable CXXTEST_TESTSUITES dans dir/Makefile_insert. Prenez garde aux barres obliques inversées « \ » à la fin des lignes. Notez que vous devez préfixer votre nom de fichier avec « $(srcdir)/dir/ », puisque c'est une variable normale non gérée par Automake, et vous devez utiliser += plutôt que =, car vous ne définissez pas cette variable mais vous y rajoutez des données.

# Faites comme cela :
CXXTEST_TESTSUITES += \
    $(srcdir)/dir/first-test.h \
    $(srcdir)/dir/second-test.h

Pour créer un test unitaire dans un répertoire qui ne contient pas encore de test unitaire :

• mettez à jour le système de construction pour Windows :
  • ajoutez un groupe cxxtestpart à la cible cxxtest dans build.xml (pour cela, copiez et modifiez un groupe existant),
  • ajoutez le fichier .o correspondant dans la liste d'exclusion de la cible lib dans build.xml et dans la liste d'inclusion de la cible linkcxxtests ;
• pour Unix, il n'y a rien d'autre à faire qu'ajouter le fichier à CXXTEST_TESTSUITES dans Makefile_insert.

Lancer des tests d'intégration

Pour les tests unitaires, il n'y a pas de problème ; mettez juste en place quelque chose qui exécute cxxtests et vous pouvez utiliser l'un des fichiers log qu'il crée pour voir ce qui s'est passé.

Pour pouvoir lancer les tests de rendu sous Windows sans avoir à les surveiller, vous devez compiler Inkscape comme un exécutable en ligne de commande pour empêcher les messages d'erreur d'exécution CRT (ou quelque chose de similaire) de surgir. Sous Linux et les autres Unix, il n'y a pas ce problème.

Le fichier teststatus.json qui est généré par runtests.py contient tous les résultats des tests (au format JSON). Notez que si vous n'exécutez qu'un sous-ensemble des tests, ce fichier conserve toutes les informations sur les tests qui ne font pas partie de ce sous-ensemble. Il conserve également les anciens résultats des tests. Les codes de résultat dans ce fichier peuvent être interprétés comme dans runtests.py (par exemple, 0, 1 et 2 signifient « succès », « échec » et « nouveau », respectivement).

Analyser la couverture de tests

Pour voir quelle quantité de code est couverte par les tests (unitaires), ou pour comparer la couverture des tests de rendu par rapport aux tests unitaires, gcov peut être utilisé. Voyez la page Profilage du wiki pour plus d'informations sur l'utilisation de gcov et coverage.py (un outil pour mettre en forme la masse de données que gcov peut générer).