Tests unitaires, tests d'intégration et fonctionnels, etc.

SJ: WIP

Ressources

- Voir la page https://wiki.eclipse.org/Eclipse/Testing qui décrit les méthodes utilisées dans le cadre du développement d'Eclipse même. Notamment un tableau comparatif en fin de page pour les tests de GUI.

- Voir JUnit Plug-in Test Launcher http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/launchers/junit_launcher.htm, launcher pour headless tests et UI tests, nécessite de faire les tests sur tous les OS

- Voir aussi les solutions de type Container, ex. : https://www.docker.com/what-docker

Notes MD

Outils

  • Cobertura : statistiques de couverture du code par les tests unitaires
  • Buckminster : plugin Eclipse pour l'automatisation du déploiement d'application : unit testing, integration testing, field deployment, staged migration, etc.
  • Tycho
  • SWTbot : tests unitaires pour SWT et Eclipse
  • CruiseControl : automatisation de build et suivi des tests
  • customTargets.xml
  • codecov
  • Gerrit : code review

Doc

Tuto et exemples

Jeux de tests

Proposition d'une architecture de tests

Un test vérifie un ou plusieurs points. Pour faire cela il peut créer un ou plusieurs résultats, importer/charger un corpus.

Chaque étape d'un test peut être remise en cause à chaque version de TXM par la personne qui test → Groovy

Il faut pouvoir accéder aux synthèses des tests de la version précédente de TXM → SVN

Les phases d'un test :

  1. création de résultat(s) → create.groovy
  2. synthétisation de résultat(s) sous forme d'un fichier lisible facilement (tableau) → export.groovy
  3. vérification de la synthèse avec retour positif ou négatif → test.groovy

Un test peut être composé des phases 1 ou 1+2 ou 1+2+3.

Une interface permet de lancer un test et de relancer tout ou partie d'un test.

Les tests et les exports par version sont stockés dans le package : “org.txm.scripts.tests” des scripts utilisateurs. L'extension “org.txm.core.tests” installe les fichiers.

Fichiers de l'extension :

  • projet “org.txm.core.tests”
    • src
      • groovy
        • org
          • txm
            • scripts
              • tests
                • test1
                  • create.groovy
                  • export.groovy
                  • test.groovy
                  • 079.txt (export de la version précédente de TXM)
                  • 080.txt (export de la version courante de TXM)

Dans les scripts utilisateurs une fois l'extension installée :

  • TXMHOME
    • scripts
      • groovy
        • user
          • org
            • txm
              • scripts
                • tests
                  • test1
                    • create.groovy
                    • export.groovy
                    • test.groovy
                    • 079.txt
                    • 080.txt
                    • create.logs
                    • export.logs
                    • test.logs

L'extension “org.txm.rcp.tests” donne accès aux tests dans un éditeur. L'éditeur est alimenté par les tests du répertoire “TXMHOME/scripts/groovy/user/org/txm/scripts/tests” et permet de :

  • lancer les tests à partir des phases disponibles : create, export et test
  • éditer les scripts Groovy des phases
  • voir l'état (+logs) 'absent', 'réussi' ou 'échec' de chaque phase
  • voir les fichiers de synthèses et ouvrir leur contenu dans l'éditeur de texte
  • créer/supprimer un test

propositions

Discussion/propositions specs sur les tests à mettre en place, et en particulier pour valider les gros changements inclus dans la 0.7.9.

Notes :

  • utiliser des diff ou une fonction de hashage sur les fichiers générés
  • l'import et la tokenisation ne devraient a priori pas changer entre la 0.7.8 et la 0.7.9 (vérifier quand même qu'il n'y a pas eu de la correction de bugs sur le tokenizer)
  • certains graphiques on changé (titre, etc.) donc les comparaisons ne pourront pas toutes se faire entre la 0.7.8 et la 0.7.9
  • la majeure partie des commandes n'a pas changé (vérifier ce point avec Matt)
  • problème : la majeure partie des commandes est basée sur des outils tiers dont nous livrons des binaires/libs différents sur les 3 OS, donc les tests doivent être faits sur les 3 OS ?

Corpus de tests

  • avant tout, vérifier que les corpus sont bien de la même version (hash/diff sur le répertoire corpora)

Import

  • ⇒ hash/diff des fichiers XML-TXM
  • ⇒ hash/diff des fichiers CWB

Tokenizer

  • a priori les tests sur les fichiers XML-TXM et CWB devraient couvrir le tokenizer mais ça peut être utile de séparer ces tests

Commandes

Notes :

  • pour CWB ⇒ exporter des résultats dans des fichiers depuis CQP et comparer directement les sorties CQP/CWB ?
  • idem pour R ?
  • Diagnostic/info
  • ⇒ hash/diff du fichier HTML
  • Partition
  • ⇒ JUnit : coder en dur le nombre de parties, etc. d'un résultat 0.7.8 et faire la comparaison
  • Concordance
  • ⇒ JUnit : coder en dur le nombre de résultats, etc. d'un résultat 0.7.8 et faire la comparaison
  • ⇒ vérifier chaque ligne de résultat une à une ?
  • Table Lexicale
  • ⇒ JUnit : coder en dur le nombre de résultats, etc. d'un résultat 0.7.8 et faire la comparaison
  • ⇒ faire les tests en se basant sur un export de table ? plus simple mais moins fiable.
  • Editions
  • ⇒ hash/diff des fichiers HTML/CSS

Export

  • Corpus
  • ⇒ hash/diff du fichier .zip/.txm
  • Graphiques
  • ⇒ hash/diff entre des fichiers générés à la main dans la 0.7.8 et automatiquement dans la 0.7.9 (svg, jpeg, png, etc. avec le moteur R et le moteur Java 2D)
  • Table Lexicale
  • ⇒ hash/diff du fichier CSV/TSV

Tests des résultats dans l'UI

  • par sérialisation des composants graphiques
  • ⇒ une idée, comme ça…
  • par hash/diff de screenshots
  • ⇒ autre idée.
  • JUnit : par copier/coller du tableau de résultats dans un fichier puis hash/diff entre une version 0.7.8 et 0.7.9
public/code_testing.txt · Dernière modification: 2019/01/16 15:38 par matthieu.decorde@ens-lyon.fr