Kątomierz - przewodnik po stylu dla kątomierza

W tym rozdziale szczegółowo zapoznajmy się ze wskazówkami dotyczącymi stylu kątomierza.

Wprowadzenie

Przewodnik po stylu został stworzony przez dwóch inżynierów oprogramowania, Carmen Popoviciu, inżynier front-end w ING i Andres Dominguez, inżynier oprogramowania w Google. W związku z tym ten przewodnik stylistyczny nosi również nazwę Carmen Popoviciu i jest przewodnikiem stylu Google dotyczącym kątomierza.

Ten przewodnik po stylu można podzielić na pięć następujących kluczowych punktów:

  • Zasady ogólne
  • Struktura projektu
  • Strategie lokalizacyjne
  • Obiekty strony
  • Zestawy testowe

Zasady ogólne

Poniżej przedstawiono kilka ogólnych zasad, na które należy zwrócić uwagę podczas testowania kątomierza -

Nie testuj od końca do końca tego, co zostało już przetestowane jednostkowo

To pierwsza ogólna reguła podana przez Carmen i Andresa. Zasugerowali, że nie możemy przeprowadzać testu e2e na kodzie, który został już przetestowany jednostkowo. Głównym powodem jest to, że testy jednostkowe są znacznie szybsze niż testy e2e. Innym powodem jest to, że musimy unikać podwójnych testów (nie przeprowadzaj testów jednostkowych i e2e), aby zaoszczędzić czas.

Użyj tylko jednego pliku konfiguracyjnego

Kolejnym ważnym punktem, który zalecamy, jest to, że musimy używać tylko jednego pliku konfiguracyjnego. Nie twórz pliku konfiguracyjnego dla każdego testowanego środowiska. Możesz użyćgrunt-protractor-coverage w celu skonfigurowania różnych środowisk.

Unikaj używania logiki podczas testu

Musimy unikać używania instrukcji IF lub pętli FOR w naszych przypadkach testowych, ponieważ jeśli to zrobimy, test może przejść bez testowania czegokolwiek lub może działać bardzo wolno.

Uczyń test niezależnym na poziomie pliku

Protractor może uruchomić test równolegle, gdy udostępnianie jest włączone. Pliki te są następnie wykonywane w różnych przeglądarkach, gdy staną się dostępne. Carmen i Andres zalecili, aby test był niezależny przynajmniej na poziomie pliku, ponieważ kolejność, w jakiej będą wykonywane przez kątomierz, jest niepewna, a ponadto dość łatwo jest przeprowadzić test w izolacji.

Struktura projektu

Kolejną ważną kwestią dotyczącą przewodnika po stylu Protractor jest struktura projektu. Poniżej znajduje się zalecenie dotyczące struktury projektu -

Obmacywanie testu e2e w rozsądnej strukturze

Carmen i Andres zalecili, abyśmy zgrupowali nasze testy e2e w strukturę, która ma sens dla struktury Twojego projektu. Powodem tego zalecenia jest to, że znajdowanie plików stałoby się łatwe, a struktura folderów byłaby bardziej czytelna. Ten krok oddzieli również testy e2e od testów jednostkowych. Zalecili unikanie następującego rodzaju konstrukcji -

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

Z drugiej strony zalecili następujący rodzaj konstrukcji -

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

Poniżej przedstawiono niektóre strategie lokalizatora, które należy zachować ostrożność podczas korzystania z kątomierza do testowania -

Nigdy nie używaj XPATH

Jest to pierwsza strategia lokalizacyjna zalecana w przewodniku po kątomierzach. Powodem tego samego jest to, że XPath wymaga wielu czynności konserwacyjnych, ponieważ znaczniki bardzo łatwo podlegają zmianom. Ponadto wyrażenia XPath są najwolniejsze i bardzo trudne do debugowania.

Zawsze preferuj lokalizatory specyficzne dla kątomierza, takie jak by.model i by.binding

Lokalizatory specyficzne dla kątomierza, takie jak by.model i by.binding są krótkie, konkretne i łatwe do odczytania. Z ich pomocą bardzo łatwo jest napisać również nasz lokalizator.

Przykład

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>

W przypadku powyższego kodu zaleca się unikanie następujących -

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

Z drugiej strony zaleca się użycie -

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

Gdy nie są dostępne żadne lokalizatory Protractor, zaleca się wybranie by.id i by.css.

Zawsze unikaj lokalizatorów tekstu dla często zmieniającego się tekstu

Musimy unikać lokalizatorów opartych na tekście, takich jak by.linkText, by.buttonText i by.cssContaningText, ponieważ tekst przycisków, linków i etykiet często zmienia się w czasie.

Obiekty strony

Jak wspomniano wcześniej, obiekty strony hermetyzują informacje o elementach na naszej stronie aplikacji i dzięki temu pomagają nam pisać czystsze przypadki testowe. Bardzo użyteczną zaletą obiektów strony jest to, że można je ponownie wykorzystać w wielu testach, aw przypadku zmiany szablonu naszej aplikacji wystarczy zaktualizować obiekt strony. Poniżej znajdują się zalecenia dotyczące obiektów strony, na które należy uważać podczas testowania kątomierza -

Aby wejść w interakcję z testowaną stroną, użyj obiektów strony

Zaleca się używanie obiektów strony do interakcji z testowaną stroną, ponieważ mogą one zawierać informacje o elemencie na testowanej stronie, a także mogą być ponownie użyte.

Zawsze deklaruj obiekt jednostronicowy na plik

Powinniśmy zdefiniować każdy obiekt strony w jego własnym pliku, ponieważ utrzymuje on kod w czystości, a znajdowanie rzeczy staje się łatwe.

Na końcu strony plik obiektowy zawsze używa pojedynczego module.exports

Zaleca się, aby każdy obiekt strony deklarował jedną klasę, abyśmy musieli wyeksportować tylko jedną klasę. Na przykład należy unikać następującego użycia pliku obiektowego -

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

Ale z drugiej strony zaleca się użycie -

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

module.exports = UserPropertiesPage;

Zadeklaruj wszystkie wymagane moduły u góry

Powinniśmy zadeklarować wszystkie wymagane moduły u góry obiektu strony, ponieważ dzięki temu zależności modułów są jasne i łatwe do znalezienia.

Utwórz wystąpienie wszystkich obiektów strony na początku zestawu testów

Zaleca się utworzenie instancji wszystkich obiektów strony na początku zestawu testów, ponieważ spowoduje to oddzielenie zależności od kodu testowego, a także udostępnienie zależności dla wszystkich specyfikacji zestawu.

Nie używaj Expect () w obiektach strony

Nie powinniśmy używać Expect () w obiektach strony, tj. Nie powinniśmy robić żadnych asercji w naszych obiektach strony, ponieważ wszystkie asercje muszą być wykonywane w przypadkach testowych.

Innym powodem jest to, że czytelnik testu powinien być w stanie zrozumieć zachowanie aplikacji, czytając tylko przypadki testowe.