Winkelmesser - Style Guide für Winkelmesser

In diesem Kapitel erfahren Sie mehr über den Styleguide für Winkelmesser.

Einführung

Der Styleguide wurde von zwei Software-Ingenieuren mit dem Namen erstellt. Carmen Popoviciu, Front-End-Ingenieur bei ING und Andres Dominguez, Softwareentwickler bei Google. Daher wird dieser Styleguide auch Carmen Popoviciu und Googles Styleguide für Winkelmesser genannt.

Dieser Styleguide kann in die folgenden fünf Schlüsselpunkte unterteilt werden:

• Allgemeine Regeln
• Projektstruktur
• Locator-Strategien
• Seitenobjekte
• Testsuiten

Allgemeine Regeln

Im Folgenden sind einige allgemeine Regeln aufgeführt, die bei der Verwendung von Winkelmessern zum Testen beachtet werden müssen:

Testen Sie nicht das, was bereits in der Einheit getestet wurde

Dies ist die allererste generische Regel von Carmen und Andres. Sie schlugen vor, dass wir keinen e2e-Test für den Code durchführen dürfen, der bereits Unit-getestet wurde. Der Hauptgrund dafür ist, dass die Unit-Tests viel schneller sind als die e2e-Tests. Ein weiterer Grund ist, dass wir doppelte Tests vermeiden müssen (nicht sowohl Unit- als auch E2E-Tests durchführen), um Zeit zu sparen.

Verwenden Sie nur eine Konfigurationsdatei

Ein weiterer wichtiger Punkt, der empfohlen wird, ist, dass wir nur eine Konfigurationsdatei verwenden müssen. Erstellen Sie keine Konfigurationsdatei für jede Umgebung, die Sie testen. Sie können verwendengrunt-protractor-coverage um verschiedene Umgebungen einzurichten.

Vermeiden Sie die Verwendung von Logik für Ihren Test

Wir müssen die Verwendung von IF-Anweisungen oder FOR-Schleifen in unseren Testfällen vermeiden, da der Test in diesem Fall möglicherweise ohne Test bestanden wird oder sehr langsam abläuft.

Machen Sie den Test auf Dateiebene unabhängig

Der Winkelmesser kann den Test parallel ausführen, wenn die Freigabe aktiviert ist. Diese Dateien werden dann in verschiedenen Browsern ausgeführt, sobald sie verfügbar sind. Carmen und Andres empfahlen, den Test zumindest auf Dateiebene unabhängig zu machen, da die Reihenfolge, in der sie vom Winkelmesser ausgeführt werden, ungewiss ist und es außerdem recht einfach ist, einen Test isoliert durchzuführen.

Projektstruktur

Ein weiterer wichtiger Punkt in Bezug auf den Styleguide von Protractor ist die Struktur Ihres Projekts. Das Folgende ist die Empfehlung zur Projektstruktur -

Tappen e2e Test in einer vernünftigen Struktur

Carmen und Andres haben empfohlen, unsere e2e-Tests in einer Struktur zu gruppieren, die für die Struktur Ihres Projekts sinnvoll ist. Der Grund für diese Empfehlung ist, dass das Auffinden von Dateien einfach wird und die Ordnerstruktur besser lesbar ist. Dieser Schritt trennt auch e2e-Tests von Unit-Tests. Sie empfahlen, die folgende Art von Struktur zu vermeiden -

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

Auf der anderen Seite empfahlen sie die folgende Art von Struktur -

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

Locator-Strategien

Im Folgenden sind einige Lokalisierungsstrategien aufgeführt, die bei der Verwendung von Winkelmessern zum Testen berücksichtigt werden müssen:

Verwenden Sie niemals XPATH

Dies ist die erste Locator-Strategie, die im Winkelmesser-Styleguide empfohlen wird. Der Grund dafür ist, dass XPath viel Wartung erfordert, da Markups sehr leicht geändert werden können. Darüber hinaus sind XPath-Ausdrücke am langsamsten und sehr schwer zu debuggen.

Bevorzugen Sie immer Winkelmesser-spezifische Lokalisierer wie by.model und by.binding

Winkelmesser-spezifische Lokalisierer wie by.model und by.binding sind kurz, spezifisch und leicht zu lesen. Mit ihrer Hilfe ist es sehr einfach, auch unseren Locator zu schreiben.

Beispiel

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>

Für den obigen Code wird empfohlen, Folgendes zu vermeiden:

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

Auf der anderen Seite wird Folgendes empfohlen:

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

Wenn keine Winkelmesser-Locators verfügbar sind, wird empfohlen, by.id und by.css zu bevorzugen.

Vermeiden Sie immer Textlokalisatoren für häufig wechselnden Text

Wir müssen textbasierte Locators wie by.linkText, by.buttonText und by.cssContaningText vermeiden, da sich der Text für Schaltflächen, Links und Beschriftungen im Laufe der Zeit häufig ändert.

Seitenobjekte

Wie bereits erwähnt, enthalten Seitenobjekte Informationen zu den Elementen auf unserer Anwendungsseite und helfen uns daher, sauberere Testfälle zu schreiben. Ein sehr nützlicher Vorteil von Seitenobjekten besteht darin, dass sie über mehrere Tests hinweg wiederverwendet werden können. Falls die Vorlage unserer Anwendung geändert wurde, müssen wir nur das Seitenobjekt aktualisieren. Im Folgenden finden Sie einige Empfehlungen für Seitenobjekte, die bei der Verwendung von Winkelmessern zum Testen berücksichtigt werden müssen.

Verwenden Sie Seitenobjekte, um mit der zu testenden Seite zu interagieren

Es wird empfohlen, Seitenobjekte für die Interaktion mit der zu testenden Seite zu verwenden, da diese Informationen über das Element auf der zu testenden Seite enthalten und auch wiederverwendet werden können.

Deklarieren Sie immer ein einseitiges Objekt pro Datei

Wir sollten jedes Seitenobjekt in einer eigenen Datei definieren, da es den Code sauber hält und das Auffinden von Dingen einfach wird.

Am Ende der Seite verwendet die Objektdatei immer ein einzelnes module.exports

Es wird empfohlen, dass jedes Seitenobjekt eine einzelne Klasse deklariert, damit nur eine Klasse exportiert werden muss. Beispielsweise sollte die folgende Verwendung von Objektdateien vermieden werden:

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

Auf der anderen Seite wird empfohlen, Folgendes zu verwenden:

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

module.exports = UserPropertiesPage;

Deklarieren Sie oben alle erforderlichen Module

Wir sollten alle erforderlichen Module oben im Seitenobjekt deklarieren, da dadurch die Modulabhängigkeiten klar und leicht zu finden sind.

Instanziieren Sie alle Seitenobjekte zu Beginn der Testsuite

Es wird empfohlen, alle Seitenobjekte zu Beginn der Testsuite zu instanziieren, da dadurch Abhängigkeiten vom Testcode getrennt werden und die Abhängigkeiten für alle Spezifikationen der Suite verfügbar sind.

Verwenden Sie erwartungs () nicht in Seitenobjekten

Wir sollten require () nicht in Seitenobjekten verwenden, dh wir sollten keine Zusicherungen in unseren Seitenobjekten machen, da alle Zusicherungen in Testfällen erfolgen müssen.

Ein weiterer Grund ist, dass der Leser des Tests das Verhalten der Anwendung nur durch Lesen der Testfälle verstehen kann.