Apache OFBiz® Selenium-WebDriver

Chaque test doit tester une fonctionnalité bien identifiée.
Chaque test doit être systématique dans le test, si possible tester tous les boutons, tous les messages d’erreur, mais dans un cadre de base.
Le passage des tests unitaires doit être assez rapide, car ils doivent permettre de repérer les erreurs les plus évidentes.
Les données utilisés pour ces tests sont le plus souvent des données dédiées, insérées dans la base via le load ext-test. Il n’y a pas besoin que les données soit significative.

La correction d’une erreur sur un test unitaire doit être assez rapide car le périmètre du test est précis.
Un test unitaire n’a pas pour objet d’être utilisé par un test de type scénario, donc s’il doit y avoir des parties de code commune, il faut mettre dans une méthode séparée cette partie de code commune (attendre le besoin pour le faire).
A l’opposé, les tests de type scénario font appel à des méthodes simples d’action qui doivent être utilisé dans un test unitaire.
Le nombre de message de log est limité, c’est plutôt les messages d’assert qui permettent de comprendre rapidement où le test a échoué. C’est plutôt des messages de log que des showInfoPanel.

Enchaîner un ensemble d’action correspondant à un cas d’usage utilisateur, que ce soit au sein d’une même application ou multi-application (back - front - portail).
Le test doit se limiter à un cas d’usage, il faut faire 3 tests plutôt qu’un seul test mélangeant des cas. Un cas d’usage peut être simple, exemple : validation d’un article, ou correspondre à l’explication de l’usage d’une notion, exemple : caractéristique article et front
Passé au ralenti, un test scénario peux servir de tutoriel, il faut donc avoir des showInfoPanel explicite fonctionnellement.
Les données doivent être explicites et dédiées, les données de base devant exister au par-avant peuvent être chargées via un scénario dédié qui passe juste avant le lancement du test.

Un test scénario doit être constitué d’appel de méthodes utilisées par les tests unitaires.
Comme un test correspond à un cas d’usage, seul les fonctionnalités nécessaires sont testées.
Les messages de log sont surtout des showInfoPanel pour expliciter où nous nous trouvons dans le déroulement du cas d’usage. Les messages sont explicites concernant l’action à réalisé ou réalisé et les données. Bien faire la différence entre les showInfoPanel à destination de "fonctionnel" et les log à destination des "fonctionnel & technique".

L’objectif n’est pas de tester si cela fonctionne mais si ça fonctionne suffisamment rapidement avec de multiple utilisateur.
Pouvoir être lancé de très multiple fois sur un même environnement.
Durer un certain temps afin qu’il soit possible de lancer de multiple instance du test sans que la première instance se termine avant que la dernière instance ne soit démarré.
Le test doit se limiter à un cas d’usage, mais pour respecter la notion de durée, il est possible pour un test d’enchaîner plusieurs fois le même cas d’usage.

Un test performance doit être constitué d’appel de méthodes utilisées par les tests scénario.
Les contraintes se trouvent surtout au niveau de l’infrastructure permettant de lancer multiple instance en même temps.

Cette méthode permet de générer des messages à l’attention d’un "utilisateur" qui regarderait l’enregistrement vidéo du déroulement d’un test. Ces messages apparaissent aussi dans le fichier de log.

Il y a deux principaux cas d’usage :

Toute entrée dans une méthode commencera par un signalement clair (cible utilisateur lambda + information informatique), si cela aide un des deux utilisateurs potentiel (cf cas d’usage ci-dessus), par exemple, il n’est pas nécessaire de préciser le début des méthodes "techniques".

Chaque fois que c’est possible indiquer les données utilisées pour l’action à venir (cela aide à reproduire le test) > LogSelenium.showInfoPanel(module, source, "Affichage des relations (" + partyId + ")", 1);

Cette méthode permet de générer des messages dans le fichier de log à l’attention des "réalisateurs / débuggers" de test, qu’ils soient technique ou fonctionnel (ou les deux ;-).

Afin que les logs soit lisibles, il est important de mettre des messages à valeur ajoutée, c’est à dire permettant de comprendre l’avancement du test et au besoin avec des données utilisées ou lues par le test.
Il ne faut pas mettre trop de message non plus.
Dans le fichier de log, le message s’affiche sur une ligne où est indiqué le nom de la méthode où il est appelé, il n’est donc pas nécessaire de le rajouter dans le message.

Les showInfoPanel peuvent perturber le déroulement d’un test, par exemple il ferme un drop-down ouvert, dans ce cas, il peut être nécessaire d’utiliser le log à la place.

Comme le fichier log peut être lu par des "fonctionnels" qui ne regarderont pas le code, il faut être en cohérence avec ce qui est mis dans la javadoc. Des méthodes purement techniques n’ont pas forcément besoin de générer des messages de log

Chacun de ces points sont explicités dans la suite

Dans le job jenkins, quand vous cliquer sur le lien du test qui a échoué, le message d’erreur c’est la 1,2 (ou 3) premières lignes qui apparaissent sous <<Message d'erreur>>

Le message est

Dans le paragraphe Pile d’exécution, la pile ressemble à quelque chose comme

avec en haut la méthode qui a provoqué l’erreur et au fur et à mesure que l’on descend les méthodes qui ont appelé celle de la ligne précédente.

Dans cet exemple on peut dire que simpleTest a appellé click qui a provoqué l’erreur (au plan fonctionnel)
sur le plan technique la méthode simpleTest est dans le fichier ExampleVuejsTestSuite.java et l’appelle à click est à la ligne 34 et la méthode click se trouve dans le fichier SimpleTestSuite.java et c’est l’exécution de la ligne 540 qui a provoqué l’erreur via l’appelle à …​.

la javadoc se trouve là
Pour aller directement sur la javadoc de la méthode désirée utilisez index (dans le menu en haut), puis vous pouvez suivre les liens.

Dans un test, quand des données sont utilisées (un offerId, un loggin, …​), c’est normalement indiqué dans la javadoc qui précise le data-obj (cf paragraphe suivant) qui est utilisé (avec une notation de type xxxxx.yyyy xxxx étant le test-case et yyyy le data-obj).

Dans l’écran où vous avez regardé, le message d’erreur (section Message d’erreur) et la pile des appels des méthodes (section Pile d’exécution), il faut descendre jusqu’à la section Sortie standard puis trouver le log concernant votre test, car la sortie concerne tous les tests du job.
Si vous avec utilisez "Gradle selenium Result", il y a un bouton "Standard Output" pour aller directement dedans.

Pour trouver le début du log du test qui vous intéresse, cherchez avec le nom du test

Ce log est censé être compréhensible y compris dans une optique fonctionnelle, au fur et à mesure de son usage il est important d’améliorer son contenu en ayant des messages précis et avec l’affichage de données en cours permettant de se retrouver facilement dans le déroulement du test.

Toutes les données saisies ou à vérifier, dans les tests sont dans des fichiers externes aux tests, il y a normalement/classiquement un fichier par package (c’est une convention de nommage pas une obligation technique) au format xml et dans chaque fichier on va trouver au minimum 4 niveaux hiérarchiques :

Les fichiers data se trouve dans le répertoire du projet OfbSwd dans le sous-répertoire test-data.

Beaucoup d’Id sont générés par le système (partyId, N° de commande, …​), donc pour retrouver les id générés lors du test afin de pouvoir les visualiser dans l’application (s’il n’y a pas de critère de recherche simple) il est nécessaire de lire les log, normalement si un id est utilisé suite à sa création il doit être affiché dans un des message de log.

Il existe plusieurs environnements de test, 1 par version d’ofbiz de test :

Par défaut, comme un test est dépendant des données en base et de son jeu de données associé, il ne peut pas être rejoué une seconde fois dans le même environnement avec les mêmes données. Cette contrainte nous semble inacceptable, aussi nous nous imposons une bonne pratique pour la dépasser.
Dans les bonnes pratiques, nous avons implémenté le fait d’indexer les données essentiel de manière à pouvoir lancer un test plusieurs fois sur le même environnement.
Pour cela, il faut que le job est un paramètre buildNumber qui permette de le modifier en relancant le job?

En pratique cela veux dire que pour certaine données, il ne faut pas seulement lire le fichier de données, il faut aussi lire le log pour connaître l’index utilisé pour ce test.
En effet, si par exemple, le "nom" doit être unique, dans le fichier data "nom" sera de type indexed et aura comme valeur (par exemple) Martin, et lors de l’execution si le buildNumber est 2 c’est Martin2 qui sera utilisé pour le test.