17. Автоматическое тестирование

Автоматическое тестирование — важнейшая часть современного процесса разработки SAPUI5/Fiori-приложений. Оно позволяет:

  • Быстро выявлять ошибки на ранних этапах,
  • Упрощать рефакторинг,
  • Гарантировать стабильность при обновлениях зависимостей и платформы,
  • Экономить время на ручном тестировании.

Виды тестов

1. Unit-тесты (модульные)

Проверяют отдельные функции, классы, утилиты.
Рекомендуемые инструменты:

  • QUnit — стандарт для UI5, интегрируется из коробки.
  • Jest — для TypeScript/ES6-утилит, если они вынесены отдельно.

Best practice:

  • Выносите бизнес-логику из контроллеров в отдельные сервисы/утилиты — их проще тестировать.
  • Не тестируйте UI5-фреймворк, тестируйте свою логику.

2. Интеграционные тесты

Проверяют взаимодействие между модулями, работу с моделями, сервисами, роутингом.

Best practice:

  • Используйте QUnit для интеграционных сценариев (например, загрузка данных, обработка ошибок).
  • Мокируйте внешние сервисы (OData, REST) через sinon.js или встроенные возможности QUnit.

3. UI/End-to-End тесты

Проверяют работу приложения "глазами пользователя": клики, ввод данных, переходы между экранами.

Рекомендуемые инструменты:

  • OPA5 — стандарт для UI5, позволяет писать сценарии на "человеческом" языке.
  • wdi5 — современный инструмент для e2e-тестов UI5-приложений на базе WebdriverIO (поддерживает CI/CD, интеграцию с Jenkins/GitHub Actions).

Best practice:

  • Покрывайте smoke-тестами основные пользовательские сценарии (логин, создание/редактирование/удаление сущности, навигация).
  • Не пытайтесь покрыть UI-тестами всё — они дорогие в поддержке, фокусируйтесь на критичных бизнес-процессах.

Как организовать тесты в проекте

  • Все тесты (unit, integration, opa) складывайте в папку /webapp/test или /test.
  • Для QUnit/OPA5 используйте стандартную структуру: 
    /webapp
  /test
    /unit
    /integration
    /opa
  • Для wdi5 — отдельная папка /e2e в корне.

Интеграция с CI/CD

  • Запускайте тесты автоматически при каждом коммите/мерже (например, через GitHub Actions, Jenkins, GitLab CI).
  • Для QUnit/OPA5 используйте headless-браузеры (Chrome Headless, Puppeteer).
  • Для wdi5 — настройте запуск в Docker-контейнере или на выделенном runner.

Советы и best practices

  • Пишите тестируемый код: выносите бизнес-логику из контроллеров, избегайте "жёстких" зависимостей.
  • Мокируйте всё внешнее: не полагайтесь на реальные сервисы/бэкенды в unit/integration-тестах.
  • Проверяйте не только happy path: тестируйте ошибки, пустые ответы, edge cases.
  • Документируйте сценарии: описывайте, что именно проверяет каждый тест.
  • Не забывайте про линтеры и статический анализ — это тоже часть автоматизации качества (см. раздел "Линтеры").

Когда тесты необходимы, а когда — нет (с примерами)

Когда тесты обязательны

  1. Критичная бизнес-логика

    • Пример: расчёт итоговой суммы заказа с учётом скидок, налогов, валют.
    • Почему: ошибка приведёт к финансовым потерям или юридическим проблемам.
    • Как тестировать: unit-тесты для функций расчёта, интеграционные тесты для проверки взаимодействия с моделью данных.

  2. Сложные пользовательские сценарии

    • Пример: многошаговый wizard по созданию документа, где на каждом шаге свои проверки и ветвления.
    • Почему: легко сломать при доработках, сложно проверить вручную все варианты.
    • Как тестировать: e2e-тесты (OPA5/wdi5), unit-тесты для отдельных шагов.

  3. Миграции, рефакторинг, обновление зависимостей

    • Пример: переход с UI5 1.71 на 1.120, массовое переименование моделей или сервисов.
    • Почему: велик риск незаметно сломать что-то в разных частях приложения.
    • Как тестировать: запуск всего набора unit и e2e-тестов после изменений.

  4. Массовое использование переиспользуемых компонентов

    • Пример: общий компонент выбора даты, который используется на 20+ экранах.
    • Почему: баг в компоненте затронет всё приложение.
    • Как тестировать: unit-тесты для компонента, интеграционные тесты для типовых сценариев.

  5. Интеграция с внешними сервисами

    • Пример: интеграция с платёжным шлюзом, отправка данных в SAP backend.
    • Почему: ошибки могут привести к потере данных или некорректной работе бизнес-процессов.
    • Как тестировать: мокирование внешних сервисов, unit и интеграционные тесты.

Когда тесты не обязательны (но всё равно полезны)

  1. Временные прототипы, MVP

    • Пример: быстрый прототип для демонстрации заказчику, который не пойдёт в продакшн.
    • Почему: код будет выброшен, нет смысла тратить время на покрытие тестами.

  2. Мелкие визуальные правки

    • Пример: поменяли цвет кнопки, поправили отступы, изменили текст на экране.
    • Почему: такие изменения легко проверить глазами, автоматизация не окупится.

  3. Одноразовые скрипты/утилиты

    • Пример: скрипт миграции данных, который запускается один раз вручную.
    • Почему: проще проверить вручную, чем писать тесты для кода, который больше не понадобится.

  4. Очень простые компоненты

    • Пример: компонент, который просто отображает статический текст или иконку.
    • Почему: вероятность ошибки минимальна, тесты не дадут дополнительной ценности.

Граничные случаи

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

Полезные ссылки

Резюме:
Тесты — это инструмент управления рисками. Чем выше цена ошибки, тем нужнее автоматизация. Но не стоит стремиться к 100% покрытию любой ценой — разумный баланс между затратами и выгодой всегда важнее.

См. также