Goniometro - Guida allo stile per goniometro

In questo capitolo, impariamo in dettaglio la guida allo stile per il goniometro.

introduzione

La guida allo stile è stata creata da due ingegneri del software denominati, Carmen Popoviciu, ingegnere front-end presso ING e Andres Dominguez, software engineer presso Google. Quindi, questa guida di stile è anche chiamata Carmen Popoviciu e la guida di stile di Google per il goniometro.

Questa guida di stile può essere suddivisa nei seguenti cinque punti chiave:

  • Regole generiche
  • Struttura del progetto
  • Strategie di localizzazione
  • Oggetti pagina
  • Suite di test

Regole generiche

Di seguito sono riportate alcune regole generiche che devono essere prese in considerazione durante l'utilizzo del goniometro per i test:

Non testare end-to-end ciò che è già stato testato in unità

Questa è la prima regola generica data da Carmen e Andres. Hanno suggerito che non dobbiamo eseguire il test e2e sul codice che è già stato unit test. Il motivo principale è che i test unitari sono molto più veloci dei test e2e. Un altro motivo è che dobbiamo evitare i test duplicati (non eseguire test sia unitari che e2e) per risparmiare tempo.

Utilizza un solo file di configurazione

Un altro punto importante consigliato è che dobbiamo utilizzare un solo file di configurazione. Non creare file di configurazione per ogni ambiente che stai testando. Puoi usaregrunt-protractor-coverage per allestire ambienti diversi.

Evita di usare la logica per il tuo test

Dobbiamo evitare di usare istruzioni IF o cicli FOR nei nostri casi di test perché se lo facciamo, il test potrebbe passare senza testare nulla o potrebbe essere eseguito molto lentamente.

Rendi il test indipendente a livello di file

Goniometro può eseguire il test parallelamente quando la condivisione è abilitata. Questi file vengono quindi eseguiti su browser diversi non appena diventano disponibili. Carmen e Andres consigliano di rendere il test indipendente almeno a livello di file perché l'ordine in cui verranno eseguiti dal goniometro è incerto ed inoltre è abbastanza facile eseguire un test in isolamento.

Struttura del progetto

Un altro punto chiave importante per quanto riguarda la guida allo stile di Goniometro è la struttura del tuo progetto. Quanto segue è la raccomandazione sulla struttura del progetto:

Tentare e2e test in una struttura sensibile

Carmen e Andres ci hanno consigliato di raggruppare i nostri test e2e in una struttura che abbia senso per la struttura del tuo progetto. Il motivo alla base di questa raccomandazione è che la ricerca dei file diventerebbe facile e la struttura delle cartelle sarebbe più leggibile. Questo passaggio separerà anche i test e2e dai test unitari. Hanno raccomandato di evitare il seguente tipo di struttura:

|-- 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'altra parte, hanno raccomandato il seguente tipo di struttura:

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

Strategie di localizzazione

Di seguito sono riportate alcune strategie di localizzazione che devono essere prese con cura durante l'utilizzo del goniometro per i test:

Non utilizzare mai XPATH

Questa è la prima strategia di localizzazione consigliata nella guida allo stile del goniometro. Le ragioni alla base dello stesso è che XPath richiede molta manutenzione perché il markup è molto facilmente soggetto a modifiche. Inoltre, le espressioni XPath sono le più lente e molto difficili da eseguire il debug.

Preferisci sempre localizzatori specifici del goniometro come by.model e by.binding

I localizzatori specifici del goniometro come by.model e by.binding sono brevi, specifici e di facile lettura. Con l'aiuto di loro è molto facile scrivere anche il nostro localizzatore.

Esempio

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>

Per il codice sopra, si consiglia di evitare quanto segue:

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

D'altra parte, si consiglia di utilizzare:

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

Quando non sono disponibili localizzatori del goniometro, si consiglia di preferire by.id e by.css.

Evita sempre i localizzatori di testo per cambiare testo frequentemente

Dobbiamo evitare i localizzatori basati su testo come by.linkText, by.buttonText e by.cssContaningText perché il testo per pulsanti, link ed etichette cambia frequentemente nel tempo.

Oggetti pagina

Come discusso in precedenza, gli oggetti pagina incapsulano le informazioni sugli elementi nella nostra pagina dell'applicazione e grazie a questo ci aiutano a scrivere casi di test più puliti. Un vantaggio molto utile degli oggetti pagina è che possono essere riutilizzati in più test e nel caso in cui il modello della nostra applicazione sia stato modificato, dobbiamo solo aggiornare l'oggetto pagina. Di seguito sono riportati alcuni consigli per gli oggetti della pagina che devono essere curati durante l'utilizzo del goniometro per i test:

Per interagire con la pagina sotto test, utilizzare gli oggetti pagina

Si consiglia di utilizzare oggetti pagina per interagire con la pagina sottoposta a test perché possono incapsulare informazioni sull'elemento nella pagina sottoposta a test e possono anche essere riutilizzati.

Dichiara sempre l'oggetto di una pagina per file

Dovremmo definire ogni oggetto della pagina nel proprio file perché mantiene il codice pulito e trovare le cose diventa facile.

Alla fine della pagina il file oggetto utilizza sempre un singolo module.exports

Si consiglia che ogni oggetto della pagina dichiari una singola classe in modo che sia necessario esportare solo una classe. Ad esempio, il seguente utilizzo del file oggetto dovrebbe essere evitato:

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

Ma d'altra parte, si consiglia di utilizzare:

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

module.exports = UserPropertiesPage;

Dichiara tutti i moduli richiesti in alto

Dovremmo dichiarare tutti i moduli richiesti nella parte superiore dell'oggetto pagina perché rende le dipendenze dei moduli chiare e facili da trovare.

Crea un'istanza di tutti gli oggetti della pagina all'inizio della suite di test

Si consiglia di istanziare tutti gli oggetti della pagina all'inizio della suite di test perché questo separerà le dipendenze dal codice di test e renderà le dipendenze disponibili per tutte le specifiche della suite.

Non utilizzare wait () negli oggetti della pagina

Non dovremmo usare wait () negli oggetti della pagina, cioè non dovremmo fare alcuna asserzione nei nostri oggetti della pagina perché tutte le asserzioni devono essere fatte nei casi di test.

Un altro motivo è che il lettore del test dovrebbe essere in grado di comprendere il comportamento dell'applicazione leggendo solo i casi di test.