Les tests de formulaires et modèles de fiches

Les tests permettent d’automatiser les vérifications du bon fonctionnement d’un formulaire ou d'un modèle de fiche, après chaque modification.

Par exemple, si l’on veut simplifier la condition d’affichage d’un champ sur la cinquième page d’un formulaire, il peut s’avérer fastidieux de ressaisir le formulaire jusqu’à cette page pour s’assurer du bon affichage du champ. Avoir préalablement créé un test pour ce cas permet d’éviter ces vérifications fastidieuses : l’exécution réussie du test suite aux modifications donnera, en un clic, l’assurance que rien n’est cassé.

Créer un test

Pour accéder aux tests liés à un formulaire, il faut se rendre sur la page d’édition de celui-ci. Le lien se trouve en barre latérale.

Un test est un simple enregistrement des données d’une demande. Lors de la création d’un nouveau test, il est possible de démarrer une saisie manuelle, ou de gagner du temps en important les données d’une demande réelle. Dans les deux cas, les données pourront ensuite être modifiées librement.

Exécuter les tests

L’exécution d’un test consiste à jouer la saisie d’une demande à partir des données enregistrées. Si la saisie arrive à son terme sans rencontrer d’erreur, le test est réussi.

Les tests peuvent être lancés manuellement. Ils sont également exécutés de manière automatique à chaque modification du formulaire. Ces résultats sont attachés à la modification qui a déclenché l’exécution, ils sont donc visibles dans l’historique du formulaire.

Tester une erreur

Il est également possible de tester les cas où un formulaire doit afficher une erreur. Pour cela il faut saisir manuellement un nouveau test, puis compléter le formulaire jusqu’à rencontrer l’erreur attendue. Un bouton apparaît, qui permet d’enregistrer le test, alors même que la saisie n’est pas terminée.

Le principe est alors inversé : le test est considéré comme réussi tant que la saisie des données enregistrées provoque l’erreur attendue.

Tester un appel webservice

Lorsqu’un formulaire contient une condition basée sur un appel webservice utilisant la méthode GET, cet appel sera effectué à chaque exécution du test. Son succès sera donc dépendant du bon fonctionnement du service distant. Pour éviter cela, il est possible de simuler la réponse du service distant : aucune requête réelle ne sera effectuée, mais tout se passera comme si le service avait renvoyé la réponse prévue.

L’ajout d’une réponse s’effectue depuis la page d’un test, via le lien en barre latérale « Réponses webservice ». On doit renseigner à minima l’adresse exacte qui sera appelée, et le contenu de la réponse au format JSON. Il est possible de restreindre une réponse à certains paramètres, pour par exemple renvoyer une réponse différente en fonction de la valeur d’un paramètre de requête.

Lorsqu’un formulaire contient une condition basée sur un appel webservice utilisant une méthode différente de GET, cet appel sera bloqué afin d’éviter le déclenchement d’une modification dans un service distant à chaque exécution du test. Il est alors obligatoire de définir une réponse webservice à utiliser.

Utilisateurs de test

Pour tester la saisie d’une demande en mode connecté, il est nécessaire de renseigner un utilisateur dans les options du test.

Ces utilisateurs ne sont pas des comptes réels, gérés dans la brique « Connexion », mais des utilisateurs internes à la brique « Démarches », à l’usage exclusif des tests. On peut accéder à la liste des utilisateurs de test à partir de la page listant les tests d’un formulaire, le lien se trouve en barre latérale.

À noter que lors de la création depuis une demande existante, soumise en mode connecté, un utilisateur de test correspondant au demandeur est créé automatiquement.