Transportador - Guía de estilo para transportador

En este capítulo, aprendamos en detalle sobre la guía de estilo para transportador.

Introducción

La guía de estilo fue creada por dos ingenieros de software llamados, Carmen Popoviciu, ingeniero de front-end en ING y Andres Dominguez, ingeniero de software en Google. Por lo tanto, esta guía de estilo también se llama Carmen Popoviciu y guía de estilo de Google para transportador.

Esta guía de estilo se puede dividir en los siguientes cinco puntos clave:

  • Reglas genéricas
  • Estructura del proyecto
  • Estrategias de localización
  • Objetos de página
  • Suites de prueba

Reglas genéricas

Las siguientes son algunas reglas genéricas que deben tenerse en cuenta al usar el transportador para las pruebas:

No pruebe de un extremo a otro lo que ya se ha probado unitariamente

Esta es la primera regla genérica dada por Carmen y Andrés. Sugirieron que no debemos realizar la prueba e2e en el código que ya ha sido probado por unidad. La principal razón detrás de esto es que las pruebas unitarias son mucho más rápidas que las pruebas e2e. Otra razón es que debemos evitar las pruebas duplicadas (no realice pruebas tanto unitarias como e2e) para ahorrar tiempo.

Use solo un archivo de configuración

Otro punto importante que se recomienda es que debemos tener que usar un solo archivo de configuración. No cree un archivo de configuración para cada entorno que esté probando. Puedes usargrunt-protractor-coverage para configurar diferentes entornos.

Evite utilizar la lógica en su prueba

Debemos evitar el uso de sentencias IF o bucles FOR en nuestros casos de prueba porque si lo hacemos, la prueba puede pasar sin probar nada o puede funcionar muy lento.

Haga que la prueba sea independiente a nivel de archivo

Transportador puede ejecutar la prueba en paralelo cuando se habilita el uso compartido. Luego, estos archivos se ejecutan en diferentes navegadores a medida que están disponibles. Carmen y Andrés recomendaron hacer la prueba independiente al menos a nivel de archivo porque el orden en el que se ejecutarán mediante transportador es incierto y, además, es bastante fácil ejecutar una prueba de forma aislada.

Estructura del proyecto

Otro punto clave importante con respecto a la guía de estilo de Transportador es la estructura de su proyecto. La siguiente es la recomendación sobre la estructura del proyecto:

Prueba e2e a tientas en una estructura sensible

Carmen y Andrés recomendaron que debemos agrupar nuestras pruebas e2e en una estructura que tenga sentido para la estructura de su proyecto. La razón detrás de esta recomendación es que la búsqueda de archivos sería fácil y la estructura de carpetas sería más legible. Este paso también separará las pruebas e2e de las pruebas unitarias. Recomendaron que se evite el siguiente tipo de estructura:

|-- 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

Por otro lado, recomendaron el siguiente tipo de estructura:

|-- 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

Estrategias de localización

Las siguientes son algunas estrategias de localización que deben tenerse en cuenta al usar el transportador para realizar pruebas:

Nunca use XPATH

Esta es la primera estrategia de localización recomendada en la guía de estilo de transportador. Las razones detrás de lo mismo es que XPath requiere mucho mantenimiento porque el marcado está sujeto a cambios muy fácilmente. Además, las expresiones XPath son las más lentas y difíciles de depurar.

Prefiera siempre localizadores específicos de transportadores como by.model y by.binding

Los localizadores específicos de transportadores como by.model y by.binding son cortos, específicos y fáciles de leer. Con la ayuda de ellos también es muy fácil escribir nuestro localizador.

Ejemplo

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>

Para el código anterior, se recomienda evitar lo siguiente:

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

Por otro lado, se recomienda utilizar lo siguiente:

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'));

Cuando no hay localizadores de transportador disponibles, se recomienda preferir by.id y by.css.

Evite siempre los localizadores de texto para cambiar el texto con frecuencia

Debemos evitar los localizadores basados ​​en texto como by.linkText, by.buttonText y by.cssContaningText porque el texto de los botones, enlaces y etiquetas cambia con frecuencia con el tiempo.

Objetos de página

Como se discutió anteriormente, los objetos de página encapsulan información sobre los elementos en nuestra página de aplicación y, debido a esto, nos ayudan a escribir casos de prueba más limpios. Una ventaja muy útil de los objetos de página es que se pueden reutilizar en múltiples pruebas y, en caso de que se haya cambiado la plantilla de nuestra aplicación, solo necesitamos actualizar el objeto de página. Las siguientes son algunas recomendaciones para los objetos de página que deben tenerse en cuenta al usar el transportador para las pruebas:

Para interactuar con la página bajo prueba, use objetos de página

Se recomienda utilizar objetos de página para interactuar con la página bajo prueba porque pueden encapsular información sobre el elemento en la página bajo prueba y también se pueden reutilizar.

Declare siempre un objeto de una página por archivo

Debemos definir cada objeto de página en su propio archivo porque mantiene el código limpio y la búsqueda de cosas se vuelve fácil.

Al final de la página, el archivo de objeto siempre usa un solo módulo.

Se recomienda que cada objeto de página declare una sola clase para que solo necesitemos exportar una clase. Por ejemplo, se debe evitar el siguiente uso del archivo objeto:

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

Pero, por otro lado, se recomienda usar lo siguiente:

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

module.exports = UserPropertiesPage;

Declare todos los módulos requeridos en la parte superior

Deberíamos declarar todos los módulos requeridos en la parte superior del objeto de la página porque hace que las dependencias de los módulos sean claras y fáciles de encontrar.

Cree una instancia de todos los objetos de la página al comienzo del conjunto de pruebas

Se recomienda crear una instancia de todos los objetos de página al comienzo de la suite de prueba porque esto separará las dependencias del código de prueba y hará que las dependencias estén disponibles para todas las especificaciones de la suite.

No use esperar () en objetos de página

No deberíamos usar esperar () en objetos de página, es decir, no deberíamos hacer ninguna afirmación en nuestros objetos de página porque todas las afirmaciones deben hacerse en casos de prueba.

Otra razón es que el lector de la prueba debería poder comprender el comportamiento de la aplicación leyendo solo los casos de prueba.