3.24 Règles-test

3.24.1 - Comment faire fonctionner edition-tool en local

L’outil de reverse engineering générant une configuration et un brouillon de démarche à partir d’une application déployée est aussi limité que l’outil CYPRESS sur lequel il est basé. En effet, CYPRESS ne permet pas de réaliser un test (son objectif premier) dans lequel le navigateur change de domaine. Donc il n’est pas possible d’analyser une démarche connectée en intégration (car on passe sur le portail SP). Même en local, avec une configuration classique, cela ne fonctionne pas car on alterne entre 127.0.0.1 et localhost. Pour résoudre cela, il faut

  • modifier les données spécifiques avec la requête suivante : update exe_donnees_specifiques set simple_valeur_modifiee = REPLACE(simple_valeur_modifiee, ’localhost’, ‘127.0.0.1’);
  • modifier le code du bouchon OIDC pour remplacer les localhost par 127.0.0.1 puis compiler et redéployer le bouchon
  • paramétrer le test CYPRESS pour accéder à la démarche locale avec une URL en 127.0.0.1

3.24.2 - Les tests automatisés dans le Back

Quelques règles de base doivent être respectées :

  • Toute méthode (à minima) de chaque classe doit être couverte par un test automatisé.
  • Les tests automatisés peuvent être de granularité unitaire (cf. Tests de développement).
  • Tout test doit contenir une assertion (une vérification du résultat obtenu). Le plus efficace est d’écrire le test selon le modèle Arrange-Act-Assert.

3.24.3 - Les requêtes HTTP

Le chapitre IDE UseBruno de l’installation de poste local décrit l’usage de la collection de requêtes HTTP. Cette capitalisation des requêtes permet de tester le système. Tout comme les tests automatisés le font sur la PIC, ces requêtes permettent de tester n’importe quel environnement.

Pour utiliser la collection :

  • RAPPEL : mis à part deux APIs (les créations de token anonyme 021 et token SP 024), toutes les APIs du socle nécessitent un tokenPSL pour être appelées.
  • La première chose à faire, avant d’exécuter le groupe APIs internes de la collection (ou seulement une sous-partie) est donc de créer un token PSL SP. Pour cela, il faut :
    • A revoir à la fin de la migration vers UseBruno
    • ouvrir la requête 024
    • accéder à l’onglet Authorization
    • cliquer sur le bouton Get New Access Token
    • suivre, dans le mini-navigateur, le processus de connexion SP ou FC (attention à ne pas cliquer plusieurs fois sur un lien/bouton car le mini-navigateur n’affiche pas les temps de chargement)
    • cliquer sur le bouton Use Token une fois le token généré
    • A revoir à la fin de la migration vers UseBruno
  • Toutes les requêtes précisent, dans leur nom, le micro-service appelé, la fonctionnalité solicitée, le token utilisé (anonyme ou SP) et le résultat attendu.
  • Certaines requêtes contiennent un (ou plusieurs) test(s) post-exécution. Si la création du token OIDC avec SP n’est pas possible, certains tests seront évidemment KO : la requête 024 et tous les tests utilisant un token SP.
  • Les requêtes en dehors du groupe APIs internes ne sont pas à exécuter dans les tests classiques. Elles ne sont mises à disposition que pour capitaliser des besoins précis.

3.24.4 - Les tests en cas de modification structurelle du code du socle

Dans le socle, est considérée comme modification structurelle tout changement dans les fichiers pom.xml ou *.properties.

Ces changements nécessitent que l’ensemble du socle soit retesté dans toutes ces modalités de démarrage :

  • les tests automatisés
  • les démarrages depuis la ligne de commande
  • les démarrages depuis Eclipse

La stratégie de test de chaque modalité de démarrage varie :

  • les tests automatisés se valident eux-même. Il suffit de les lancer avec Maven.
  • les démarrages en ligne de commande se valident avec :
    • Modifier les fichiers de properties pour correctement paramétrer le proxy (. ./outils.sh PROXY FALSE si besoin)
    • Démarrer tous les applicatifs avec la commande . ./demarrerTout.sh
    • Vérifier que 4 services (admin, config, gateway et registry) et les 10 micro-services apparaissent dans le registre
    • Vérifier que les 10 micro-services apparaissent dans l’admin (admin1 // admin)
    • Vérifier que la javadoc des 10 micro-services est bien disponible dans swaggerUI
    • Ouvrir Postman, y générer un token OIDC SP (requête 024) et exécuter toute la collection sauf les requêtes du répertoire APIs des systèmes externes
    • Arrêter tous les applicatifs avec la commande . ./arreterTout.sh
  • les démarrages depuis Eclipse se valident avec :
    • Modifier les fichiers de properties pour correctement paramétrer le proxy (. ./outils.sh PROXY FALSE si besoin)
    • Démarrer en premier lieu les services SpringCloud : admin, config, gateway, nosql, redis et registry
    • Démarrer les micro-services ne nécessitant pas MongoDB : socle-referentiel, socle-referentielexterne, socle-securite, socle-soumission
    • Vérifier que 4 services (admin, config, gateway et registry) et les 10 micro-services apparaissent dans le registre
    • Vérifier que les 10 micro-services apparaissent dans l’admin (admin1 // admin)
    • Vérifier que le fichier 2-code\socle\services-cloud\service-nosql.log\pid_service-nosql_1.pid existe bien
    • Vérifier que la javadoc des 10 micro-services est bien disponible dans swaggerUI
    • Ouvrir Postman, y générer un token OIDC SP (requête 024) et exécuter la collection
    • Supprimer le fichier 2-code\socle\services-cloud\service-nosql.log\pid_service-nosql_1.pid pour arrêter la base NoSql
    • Arrêter tous les applicatifs depuis Eclipse (carré rouge dans la vue console)
    • Dans les logs du microservice soumission trouver le traceId d’une soumission (le premier terme alphanumerique entre crochet)
    • Vérifier la présence de ce traceId dans les logs du microservice configuration (à minima) pour vérifier la bonne propagation des entêtes de tracing

3.24.5 - Tests E2E

Du fait de leurs spécificités, les composants suivants ne sont pas testés par les tests automatiques de Cypress (information de 06/2022) :

  • utilisateurConnecte et recapitulatif car ils ne sont pas des composants de saisie mais uniquement d’affichage (mauvaise raison) ;
  • documents car, en mode bouchonné, tester le téléchargement n’a pas de sens et tester la présence du lien n’a que peu d’intérêt ;

Les tests doivent tester un maximum de chose. Mais ils ne doivent pas planter/échouer si une validation ou un type de contenu n’est pas connu. Par contre, il faut générer un log Cypress commençant par */!*.

/!\ Les brouillons stockées dans les sources doivent contenir toutes les données (sauf les PJ).

3.24.6 - Analyse de problème dans les tess E2E

Voici quelques cas d’erreur E2E connus et analysés :

  • une erreur dans blocObtenirTitre peut résulter d’un div.fmk-bloc>div.fr-col-12 vide. La source peut être dans la configuration : le bloc n’a pas de contenus (attention au s dans le nom de l’attribut du bloc).