Структура директорий проекта

Protractor является фреймворком для энд-ту-энд тестирования Angular и не только. Правильная организация директорий проекта играет ключевую роль в масштабируемости, удобстве поддержки и читабельности тестового кода. В типичном проекте на Protractor выделяют несколько основных директорий и файлов, которые обеспечивают логичное разделение функциональности и данных тестирования.

1. Директория e2e или tests

Главная рабочая директория для тестов часто называется e2e (end-to-end) или tests. Внутри нее располагаются все остальные компоненты тестового проекта: тестовые сценарии, конфигурации, вспомогательные модули и данные.

Структура может выглядеть следующим образом:

e2e/
 ├─ conf/
 ├─ specs/
 ├─ pages/
 ├─ data/
 ├─ utils/
 └─ reports/

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

2. Директория conf (конфигурации)

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

Пример содержимого:

conf/
 └─ protractor.conf.js

Ключевые моменты файла конфигурации:

  • specs — список тестовых файлов или шаблонов для их поиска.
  • capabilities — описание браузеров и их свойств.
  • framework — фреймворк, например jasmine или mocha.
  • onPrepare — функция, выполняемая перед запуском тестов, например для настройки репортера.
  • baseUrl — базовый URL приложения для тестов.

3. Директория specs (тестовые сценарии)

Содержит все тестовые сценарии. Обычно файлы именуются по смыслу проверяемой функциональности.

Пример структуры:

specs/
 ├─ login.spec.js
 ├─ dashboard.spec.js
 └─ userManagement.spec.js

Рекомендации по организации:

  • Один файл — один логический блок функциональности.
  • Тесты должны быть атомарными и легко читаемыми.
  • Можно использовать вложенные директории для крупных модулей приложения.

4. Директория pages (Page Object Model)

Использование шаблона Page Object повышает читаемость и поддерживаемость тестов. В этой директории размещаются классы или модули, описывающие элементы страниц и методы взаимодействия с ними.

Пример структуры:

pages/
 ├─ login.page.js
 ├─ dashboard.page.js
 └─ userManagement.page.js

Ключевые принципы:

  • Каждый класс соответствует одной странице или крупному компоненту.
  • Методы описывают действия пользователя (например, login(username, password)).
  • Локаторы элементов лучше хранить как свойства класса.

5. Директория data (тестовые данные)

Содержит все фикстуры, мок-данные и параметры тестов. Это позволяет легко изменять данные без модификации логики тестов.

Пример структуры:

data/
 ├─ users.json
 └─ config.json

Особенности:

  • Формат хранения: JSON, JS-модули или YAML.
  • Разделение данных по окружениям (dev, staging, prod) повышает гибкость.
  • Можно хранить сложные объекты для проверки форм и таблиц.

6. Директория utils (вспомогательные функции)

В ней располагаются общие утилиты для тестов: функции ожидания, генерации случайных данных, логгеры.

Пример структуры:

utils/
 ├─ waitHelper.js
 ├─ logger.js
 └─ dataGenerator.js

Рекомендации:

  • Избегать дублирования кода тестов.
  • Каждая утилита должна иметь одно назначение.
  • Поддерживать единый стиль именования и форматирования.

7. Директория reports (отчёты)

Используется для хранения результатов тестирования: логов, скриншотов и HTML-отчетов.

Пример структуры:

reports/
 ├─ screenshots/
 └─ jasmine-report.html

Ключевые моменты:

  • Скриншоты часто делаются при падении теста.
  • HTML-отчеты помогают отслеживать прогресс тестирования.
  • Можно интегрировать с CI/CD для автоматического сбора отчетов.

8. Файлы корня проекта

В корне проекта обычно находятся:

  • package.json — управление зависимостями и скриптами запуска.
  • .gitignore — исключение директорий, например node_modules или reports.
  • README.md — описание проекта и инструкции по запуску тестов.

9. Рекомендации по масштабированию

  • Разделение на модули: если приложение большое, каждая функциональная область может иметь собственные specs, pages и data.
  • Использование именованных экспортов для страниц и утилит упрощает импорт.
  • В крупных проектах удобно создавать поддиректории по типу: admin, user, api.
  • Систематическое использование Page Object Model и утилит снижает дублирование и повышает читаемость.

Правильная структура директорий позволяет проекту оставаться упорядоченным, облегчает работу команде тестировщиков и упрощает интеграцию с инструментами автоматизации и CI/CD. Она становится основой для построения надежной и масштабируемой системы тестирования.

Оглавление