Установка

Для работы необходимо вытянуть зависимости командой npm ci

Code convention

1. Константы:

• Имя константы - существительное/несколько слов обозначающих предмет, сущность.
• У константы указан тип при объявлении.
• type TrainingListResponse = TrainingResponse[]. TrainingListResponse избыточен, можно сократить и во всех методах использовать сразу TrainingResponse[].
• project -> projectTitle
• folder -> folderTitle
• content -> contentTitle
• user -> userName
• department -> departmentName
• group -> groupName
• Если объявляется общая константа на весь файлик, то сначала пишутся типы, а потом данные константы

  2. Массивы:

• Для асинхронного кода вместо for использовать встроенные функции: map() - если нужно преобразовать весь массив, forEarch() - если для каждого элемента нужно вызвать другую функцию, но исходный массив при этом не нужно преобразовать, find(), filter(), some() и т.д.
• Для синхронного кода использовать for-of.
• Для объединения нескольких массивов использовать spread, а не concat.

  3. Импорт:

• Проверять пути импорта, в файлах одного проекте допустимо использовать импорт из src/common, но не из другого проекта
• Методы/Функции:
• Имя функции начинается с глагола.
• У функции указан возвращаемый тип.
• Если в теле метода/функции нет await, то и async можно убрать.
• Для функций возвращающих void не использовать return.
• Не использовать return await.
• Если метод возвращает булево значение, метод должен начинаться с is, has. Затем идет глагол. Пример названия функции возвращающей булево значение isExistAvatar
• Нельзя импортировать сущности нижнего уровня на верхний уровень. Например, из learn нельзя импортировать на уровень common, а из common в learn - можно.

  4. Тесты:

• Константа TEST_MASK для теста одна, объявляется перед главным блоком describe.
• Не использовать в одном тесте несколько разных масок: TEST_MASK, PROJECT_MASK, CONTENT_MASK.
• Маски разные и достаточно длинные, проверять чтобы одна маска не была частью другой.
• Удаление по модели зло. Использовать удаление по маске.
• Удалять объекты, созданные тестом, один раз в after, после всех тестов, а не после каждого it.
• Если есть классы специфичные для проекта, например SpaceContentInternalAPIService, то используем только их, а не класс родитель - ContentInternalAPIService.
• Проверить необходимость beforeEach. Для создания сущностей часто достаточно before, например, если в тесте в каждом it нужен новый пользователь, но неважно к какому департаменту этот пользователь принадлежит, то в before создаем департамент, а в beforeEach пользователя.
• it следует использовать для выполнения действия и проверки ожидаемого результата, соответственно в title пишем то, что ожидаем, например “user should be added” Подробнее можно почитать тут.
• В UI-тестах внутри it не должны находится вызовы методов APIServices, в которых готовятся департаменты/пользователи/группы и т.д. Подобное выносится в before/beforeEach/afterEach/after
• Для тестов в лерен изолировать пользователей и департаменты в своем root департаменте, который удалится после тестов

  5. PageObject (PO):

• Метод PO не может создавать модель.
• Метод PO не может оперировать данными.
• В PO не может быть проверки (expect).
• Методы возвращающие WDIO элемент, приватные.
• Методы из блоков проксируются через PO.
• Публичные методы PO снабжены шагами, для ручных тестировщиков.
• Порядок методов: сначала приватные методы, возвращающие WDIO элемент, затем публичные методы.
• Методы отсортированы по алфавиту.

  6. API:

• Для вывода информации об ошибке в методе использовать функцию getResponseErrorInfo(). Шаблон для сообщения об ошибке: ${название функции, каждое слово по отдельности, глагол меняется на герундий} failed. getTrainingTypes => 'Getting training types failed'
• В функциях порядок передаваемых параметров от большего объекта к вложенным: (project, folder, content, ...).
• Внутри статического метода не используется контекст this.
• Если у класса есть родитель, то внутри статического метода ссылаемся только на текущий класс, а не на класс родитель.
• Метод API не может создавать модель.
• Порядок методов: сначала публичные методы, протектед и приватные.
• Методы отсортированы по алфавиту.
• В файле APIDataProvider все типы в названии запросов содержат “Request”. Например: ChapterRequest. В APIService типы ответов в названии содержат “Response”. Например: ChapterResponse.
• Для добавления навых заголовков в Провайдере использовать HeaderType