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.