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. Ils peuvent ensuite être complétés par les tests de workflow.

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. Si l'exécution automatique donne un résultat différent du dernier résultat connu, par exemple si une nouvelle erreur s'est produite, ce dernier apparaîtra attaché à la modification qui a déclenché l’exécution, visible 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 en barre latérale, 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. En plus de ralentir l'exécution du test, son succès sera 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.

Dépendances entre les tests

Cette fonctionnalité est particulièrement utile dans le cadre d'une application, car elle permet de tester des formulaires et des modèles de fiche qui dépendent les uns des autres.

Exemple

Prenons un formulaire qui ne doit être soumis qu'une seule fois par un même usager. Pour cela on peut imaginer une condition de sortie de page du type form_objects|current_user|count == 0. Par défaut, quand on crée un test et qu'on l'exécute, cette condition est toujours vraie, car l'utilisateur rattaché au test n'est pas un utilisateur réel et ne peut donc pas avoir de demandes qui lui sont rattachées.

Pour vérifier que cette condition fonctionne, il faut pouvoir provoquer la situation où l'utilisateur de test aurait déjà soumis une demande. C'est possible en ajoutant une dépendance :

1. Créer un test passant classique.
2. Lancer les tests.
3. Créer un deuxième test. Lors de l'édition des données, en barre latérale, cliquer sur « Modifier les dépendances », et sélectionner le test précédent.
4. Tenter de passer à la page suivante, l’erreur apparaît, cliquer sur « Marquer le test comme devant échouer ».

Détails de fonctionnement

Quand un test a des dépendances, son exécution déclenche l'exécution préalable de ces dernières. Tous les objets créés par ces dépendances, que ce soit le formulaire soumis en lui-même ou des fiches créées par le workflow, seront disponibles dans le contexte du test.

Pour que l'édition d'un test dépendant d'autres tests soit possible, il est nécessaire que ces tests aient été exécutés au moins une fois (étape 2 de l’exemple ci-dessus). En effet, si à l'exécution du test les objets sont créés, à l'édition ils n’existent pas encore : c'est alors les derniers résultats connus des dépendances qui sont disponibles dans le contexte d'édition.