Environnement de test local

Ce guide interne a pour but d’expliquer comment monter un serveur local basé sur un embedded server et des données de test. La première partie explique comment lancer directement les tests d’intégration existants, la deuxième montre comment importer et/ou créer un serveur local avec des données de test.

Lancement des tests d’intégration

Avant de pouvoir lancer les tests, le serveur doit avoir été compilé.

Les tests se lancent en un ligne de commande par le script run-test.sh:

./run-test.sh <test_id>

L’option --list pour voir tous les IDs de test possibles. Typiquement, voici un exemple qui va lancer les tests d’intégrations reg en évitant d’afficher les logs serveur dans la console (--quiet):

./run-test.sh reg --quiet
Note:

Par défaut, le répertoire temporaire utilisé sous Windows est trop long (plus de 35 caractères). Par conséquent, il est nécessaire d’utiliser l’option -R afin de spécifier un répertoire temporaire.

Afin de gagner du temps lors du développement de test, il est possible d’exécuter uniquement un seul test en lui appliquant l’annotation @Category(QuickRun.class) :

@Test
@Category(QuickRun.class)
public void testEmail() throws Exception {
    ...
}

Et ensuite de lancer le test avec le profil adéquat:

./run-test.sh <test_id> -P quick-run
Note:

Les références à QuickRun doivent être supprimées avant de publier les modifications sur GitLab.

Monter un serveur local pour des données de test

La vidéo suivante explique comment monter un serveur local avec des données de test :




Partir d’une base vide

Pour créer un serveur vierge, utiliser la commande suivante:

java -jar external/SNV4SRV-server/target/SNV4SRV-server-full-embedded.jar \
    --runtime <runtime> \
    --install
Note:

Le dossier <runtime> doit être inexistant ou vide, sinon le serveur refusera de démarrer.

Dès que le serveur est démarré, vous pourrez vous y télécharger un installer avec les identifiants de connexion initiaux saierp/bootStrap373746. Plus d’informations également dans cette documentation.

Utiliser une base de données de test

Les projets res_data contiennent des exports de données qui sont packagées pour les tests d’intégration. Elles permettent d’initialiser un serveur de test un ensemble de données cohérentes entre plusieurs modules.

Pour initialiser le serveur, cloner un des projets puis importer les données avec la commande suivante :

java -jar external/SNV4SRV-server/target/SNV4SRV-server-full-embedded.jar \
    --runtime <runtime> \
    --import <res_data> \
    --start
Info:

Le dossier <res_data> est simplement la racine du projet des données de test.

Les données de test vont être importées et le serveur démarré. Une fois en ligne, vous pourrez vous y connecter avec les identifiants enregistrés.

La vidéo suivant montre comment récupérer les identifiants et se connecter au serveur de test local :




Les utilisateurs/mot de passe sont disponibles à travers le package java du projet lié dans les dépendances. La façon la plus simple de récupérer ces informations est de laisser l’IDE ouvrir le fichier après avoir fait <ctrl>+clique sur une des constantes utilisées pour les connexions dans les fichiers de test.

Exécution des tests sur un serveur déjà démarré

Lorsque le script run-test.sh est lancé sans l’option -R, un nouveau serveur va être démarré en utilisant un dossier temporaire (/tmp/srv-<id>). L’importation des données et le démarrage du serveur peuvent prendre quelques minutes et sont difficilement optimisables.

Afin de ne plus avoir à attendre le chargement et démarrage d’un nouveau serveur, il est possible d’indiquer au script d’utiliser un dossier <runtime> utilisé par un serveur déjà en cours d’exécution. Ainsi, les tests seront directement lancés sur les données présentes en l’état.

Attention:

Le serveur en cours d’exécution doit utiliser les mêmes données que le <test_id> mentionné dans le script.

Pour illustrer le fonctionnement, commencer par démarrer un nouveau serveur de test:

java -jar external/SNV4SRV-server/target/SNV4SRV-server-full-embedded.jar \
    --runtime ~/sw4_runtime \
    --import sw4 \
    --start

Une fois que le serveur est démarré, ajouter l’annotation @Category(QuickRun.class) sur la méthode/classe désirée et lancer le script avec les paramètres suivants:

./run-test.sh sw4 -P quick-run -R ~/sw4_runtime

Le serveur en cours d’exécution sera automatiquement détecté et le test sera directement exécuté. Cela permet de pouvoir faire rapidement des modifications et nouveaux tests.

Info:

Dans ce mode, les tables dumpées sont restaurées avant d’exécuter le test. Afin de pouvoir rapidement relancer le test voulu (surtout en cas de crash après avoir modifié des données), les tables modifiées doivent être dumpées (testServer.dumpTables(...)) au début de la fonction.

Limitations connues de ce fonctionnement:

  • Si des tables non dumpées ont été modifiées, ils faudra les restaurer manuellement ou recréer le serveur de test.
  • Les tests avec le serveur de mail local ne fonctionneront pas, car ce dernier n’est pas démarré.

Utiliser le debugger avec un serveur de test local

Afin de pouvoir suivre pas-à-pas l’exécution du code, le serveur doit être lancé avec les arguments suivantes:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009 \
    -jar external/SNV4SRV-server/target/SNV4SRV-server-full-embedded.jar \
    --runtime ~/sw4_runtime \
    --start

L’utilisation du paramètre -agentlib implique que le code à chaud (dbcode) sera compilé automatiquement avec l’option -g afin d’avoir les valeurs des variables locales durant la session de debug.

Un IDE pourra ensuite attacher un debugger au serveur avec la configuration ci-dessous:

Paramètre Valeur
Debugger JPDA
Connector SocketAttach
Transport dt_socket
Host localhost
Port 9009
Timeout 10000

Une fois le debugger attaché, il suffit de mettre les points d’arrêt voulus et de lancer les différentes actions depuis le client riche.

Exporter un paquet depuis le serveur de test

Pour exporter les données du serveur en cours d’exécution, utiliser la commande export dans le prompt du serveur de la manière suivante. Le <path> doit pointer à la racine d’un des dossiers du groupe res_data.

export light <path>
Note:

Avant de committer, nettoyer les changements qui ne sont pas nécessaires.

Généralement, les seules modifications utiles sont:

  • La base de données (root/h2dump.sql)
  • Les fichiers GED (root/edms/ged)
  • Le schema de la base de données (root/schema.sql)