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

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: 2017/08/01 10:21 par matthieu.decorde@ens-lyon.fr