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.