Protractor - Guide de style pour rapporteur

Dans ce chapitre, apprenons en détail le guide de style pour rapporteur.

introduction

Le guide de style a été créé par deux ingénieurs en logiciel nommés, Carmen Popoviciu, ingénieur front-end chez ING et Andres Dominguez, ingénieur logiciel chez Google. Par conséquent, ce guide de style est également appelé Carmen Popoviciu et guide de style de Google pour rapporteur.

Ce guide de style peut être divisé en cinq points clés suivants -

Règles génériques
Structure du projet
Stratégies de localisation
Objets de page
Suites de tests

Règles génériques

Voici quelques règles génériques qui doivent être prises en compte lors de l'utilisation du rapporteur pour les tests -

Ne testez pas de bout en bout ce qui a déjà été testé unitaire

C'est la toute première règle générique donnée par Carmen et Andrés. Ils ont suggéré de ne pas effectuer de test e2e sur le code déjà testé unitaire. La principale raison derrière cela est que les tests unitaires sont beaucoup plus rapides que les tests e2e. Une autre raison est que nous devons éviter les tests en double (n'effectuez pas les tests unitaires et e2e) pour gagner du temps.

Utilisez un seul fichier de configuration

Un autre point important recommandé est qu'il ne faut utiliser qu'un seul fichier de configuration. Ne créez pas de fichier de configuration pour chaque environnement que vous testez. Vous pouvez utilisergrunt-protractor-coverage afin de mettre en place différents environnements.

Évitez d'utiliser la logique pour votre test

Nous devons éviter d'utiliser des instructions IF ou des boucles FOR dans nos cas de test, car si nous le faisons, le test peut passer sans rien tester ou il peut s'exécuter très lentement.

Rendre le test indépendant au niveau du fichier

Le rapporteur peut exécuter le test en parallèle lorsque le partage est activé. Ces fichiers sont ensuite exécutés sur différents navigateurs au fur et à mesure de leur disponibilité. Carmen et Andres ont recommandé de rendre le test indépendant au moins au niveau du fichier car l'ordre dans lequel ils seront exécutés par le rapporteur est incertain et de plus il est assez facile d'exécuter un test de manière isolée.

Structure du projet

Un autre point clé important concernant le guide de style de Protractor est la structure de votre projet. Voici la recommandation concernant la structure du projet -

Test e2e à tâtons dans une structure sensible

Carmen et Andres ont recommandé de regrouper nos tests e2e dans une structure qui correspond à la structure de votre projet. La raison derrière cette recommandation est que la recherche de fichiers deviendrait facile et que la structure des dossiers serait plus lisible. Cette étape séparera également les tests e2e des tests unitaires. Ils ont recommandé d'éviter le type de structure suivant:

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         home-page.js
         home-spec.js
         profile-page.js
         profile-spec.js
         contacts-page.js
         contacts-spec.js

D'autre part, ils ont recommandé le type de structure suivant -

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         |-- page-objects
            home-page.js
            profile-page.js
            contacts-page.js
         home-spec.js
         profile-spec.js
         contacts-spec.js

Stratégies de localisation

Voici quelques stratégies de localisation qui doivent être prises en compte lors de l'utilisation du rapporteur pour les tests -

N'utilisez jamais XPATH

Il s'agit de la première stratégie de localisation recommandée dans le guide de style du rapporteur. Les raisons derrière la même chose sont que XPath nécessite beaucoup de maintenance car le balisage est très facilement sujet à changement. De plus, les expressions XPath sont les plus lentes et les plus difficiles à déboguer.

Préférez toujours les localisateurs spécifiques aux rapporteurs tels que by.model et by.binding

Les localisateurs spécifiques aux rapporteurs tels que by.model et by.binding sont courts, spécifiques et faciles à lire. Avec leur aide, il est également très facile d'écrire notre localisateur.

Exemple

View

<ul class = "red">
   <li>{{color.name}}</li>
   <li>{{color.shade}}</li>
   <li>{{color.code}}</li>
</ul>

<div class = "details">
   <div class = "personal">
      <input ng-model = "person.name">
   </div>
</div>

Pour le code ci-dessus, il est recommandé d'éviter ce qui suit -

var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));

D'autre part, il est recommandé d'utiliser ce qui suit -

var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));

var nameElement = element(by.binding('color.name'));
var personName = element(by.model('person.name'));

Lorsqu'aucun localisateur Protractor n'est disponible, il est recommandé de préférer by.id et by.css.

Évitez toujours les localisateurs de texte pour le texte qui change fréquemment

Nous devons éviter les localisateurs textuels tels que by.linkText, by.buttonText et by.cssContaningText car le texte des boutons, des liens et des étiquettes change fréquemment avec le temps.

Objets de page

Comme indiqué précédemment, les objets de page encapsulent des informations sur les éléments de notre page d'application et, de ce fait, nous aident à écrire des cas de test plus propres. Un avantage très utile des objets de page est qu'ils peuvent être réutilisés à travers plusieurs tests et dans le cas où le modèle de notre application a été modifié, il suffit de mettre à jour l'objet de page. Voici quelques recommandations pour les objets de page qui doivent être pris en compte lors de l'utilisation du rapporteur pour les tests -

Pour interagir avec la page en cours de test, utilisez des objets de page

Il est recommandé d'utiliser des objets de page pour interagir avec la page testée car ils peuvent encapsuler des informations sur l'élément sur la page testée et ils peuvent également être réutilisés.

Toujours déclarer un objet d'une page par fichier

Nous devons définir chaque objet de page dans son propre fichier car il garde le code propre et la recherche de choses devient facile.

À la fin de la page, le fichier objet utilise toujours un seul module.

Il est recommandé que chaque objet de page déclare une seule classe afin que nous n'ayons besoin d'exporter qu'une seule classe. Par exemple, l'utilisation suivante du fichier objet doit être évitée -

var UserProfilePage = function() {};
var UserSettingsPage = function() {};
module.exports = UserPropertiesPage;
module.exports = UserSettingsPage;

Mais d'un autre côté, il est recommandé d'utiliser ce qui suit -

/** @constructor */
var UserPropertiesPage = function() {};

module.exports = UserPropertiesPage;

Déclarez tous les modules requis en haut

Nous devrions déclarer tous les modules requis en haut de l'objet de page car cela rend les dépendances de module claires et faciles à trouver.

Instanciez tous les objets de page au début de la suite de tests

Il est recommandé d'instancier tous les objets de page au début de la suite de tests car cela séparera les dépendances du code de test et rendra les dépendances disponibles pour toutes les spécifications de la suite.

N'utilisez pas expect () dans les objets de page

Nous ne devons pas utiliser expect () dans les objets page, c'est-à-dire que nous ne devons faire aucune assertion dans nos objets page car toutes les assertions doivent être faites dans des cas de test.

Une autre raison est que le lecteur du test doit être capable de comprendre le comportement de l'application en ne lisant que les cas de test.

↰ Previous page