Транспортир - руководство по стилю для транспортира

В этой главе давайте подробно узнаем о руководстве по стилю для транспортира.

Вступление

Руководство по стилю было создано двумя инженерами по имени Кармен Поповичу , фронт-инженера в ING и Андрес Домингес , инженера-программиста в Google. Следовательно, это руководство по стилю также называется Кармен Поповичу и руководство по стилю Google для транспортира.

Это руководство по стилю можно разделить на следующие пять ключевых точек:

Общие правила
Структура проекта
Стратегии локатора
Объекты страницы
Тестовые комплекты

Общие правила

Ниже приведены некоторые общие правила, которые необходимо соблюдать при использовании транспортира для тестирования:

Не проводите сквозное тестирование того, что уже было проверено модулем

Это самое первое общее правило, данное Кармен и Андрес. Они предположили, что мы не должны выполнять e2e-тестирование кода, который уже был протестирован модулем. Основная причина этого заключается в том, что модульные тесты намного быстрее, чем тесты e2e. Другая причина заключается в том, что мы должны избегать повторяющихся тестов (не выполнять тестирование как модульных, так и e2e) для экономии нашего времени.

Используйте только один файл конфигурации

Рекомендуется еще один важный момент: нам нужно использовать только один файл конфигурации. Не создавайте файл конфигурации для каждой тестируемой среды. Вы можете использовать покрытие grunt-protractor для настройки различных сред.

Избегайте использования логики в своем тесте

Мы должны избегать использования операторов IF или циклов FOR в наших тестовых примерах, потому что если мы это сделаем, то тест может пройти без проверки чего-либо или он может работать очень медленно.

Сделать тест независимым на уровне файлов

Транспортир может запустить тест параллельно, когда совместное использование включено. Эти файлы затем выполняются в разных браузерах по мере их появления. Кармен и Андрес рекомендовали сделать тест независимым, по крайней мере, на уровне файлов, потому что порядок, в котором они будут выполняться транспортиром, является неопределенным, и, кроме того, довольно легко выполнить тест в изоляции.

Структура проекта

Другим важным ключевым моментом в отношении руководства по стилю Protractor является структура вашего проекта. Ниже приводится рекомендация о структуре проекта —

Тест на ощупь e2e в разумной структуре

Кармен и Андрес рекомендовали, чтобы мы сгруппировали наши тесты e2e в структуру, которая имеет смысл для структуры вашего проекта. Причиной этой рекомендации является то, что поиск файлов станет легче, а структура папок станет более читабельной. Этот шаг также отделит e2e-тесты от юнит-тестов. Они рекомендовали избегать следующего вида структуры —

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

С другой стороны, они рекомендовали следующую структуру —

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

Стратегии Локатора

Ниже приведены некоторые стратегии локатора, которые необходимо соблюдать при использовании транспортира для тестирования:

Никогда не используйте XPATH

Это первая стратегия поиска, рекомендованная в руководстве по стилю транспортира. Причины того же — то, что XPath требует большого обслуживания, потому что разметка очень легко подвергается изменениям. Более того, выражения XPath являются самыми медленными и очень сложными для отладки.

Всегда предпочитайте специфичные для транспортира локаторы, такие как by.model и by.binding

Специфичные для транспортира локаторы, такие как by.model и by.binding, короткие, специфичные и легко читаемые. С их помощью очень легко написать и наш локатор.

пример

Посмотреть

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

Для приведенного выше кода рекомендуется избегать следующего:

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

С другой стороны, рекомендуется использовать следующее —

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

Если локаторы транспортира недоступны, рекомендуется использовать by.id и by.css.

Всегда избегайте текстовых локаторов для часто меняющегося текста

Мы должны избегать текстовых локаторов, таких как by.linkText, by.buttonText и by.cssContaningText, потому что текст для кнопок, ссылок и меток часто меняется со временем.

Объекты страницы

Как обсуждалось ранее, объекты страницы инкапсулируют информацию об элементах на странице нашего приложения и благодаря этому помогают нам писать более чистые контрольные примеры. Очень полезным преимуществом объектов страницы является то, что они могут быть повторно использованы в нескольких тестах, и в случае, если шаблон нашего приложения был изменен, нам нужно только обновить объект страницы. Ниже приведены некоторые рекомендации для объектов страницы, которые необходимо соблюдать при использовании транспортира для тестирования.

Для взаимодействия с тестируемой страницей используйте объекты страницы

Рекомендуется использовать объекты страницы для взаимодействия с тестируемой страницей, поскольку они могут инкапсулировать информацию об элементе на тестируемой странице, а также их можно использовать повторно.

Всегда объявляйте одностраничный объект на файл

Мы должны определить каждый объект страницы в своем собственном файле, потому что он сохраняет код в чистоте и поиск вещей становится легким.

В конце страницы объектный файл всегда использует один модуль.

Рекомендуется, чтобы каждый объект страницы объявлял один класс, поэтому нам нужно экспортировать только один класс. Например, следует избегать следующего использования объектного файла —

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

Но с другой стороны, рекомендуется использовать следующее —

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

module.exports = UserPropertiesPage;

Объявите все необходимые модули вверху

Мы должны объявить все необходимые модули в верхней части объекта страницы, потому что это делает зависимости модулей понятными и их легко найти.

Создание экземпляров всех объектов страницы в начале набора тестов

Рекомендуется создавать экземпляры всех объектов страницы в начале набора тестов, потому что это отделит зависимости от кода теста, а также сделает зависимости доступными для всех спецификаций набора.

Не используйте функцию ожидаем () в объектах страницы

Мы не должны использовать функцию ожидаем () в объектах страницы, т.е. мы не должны делать никаких утверждений в наших объектах страницы, потому что все утверждения должны выполняться в тестовых примерах.

Другая причина заключается в том, что читатель теста должен понимать поведение приложения, читая только контрольные примеры.

Транспортир — руководство по стилю для транспортира