Перейти к основному содержимому

Порядок работ

Golden master тестирование содержит в себе определённые нюансы использования. storyshots не является исключением, далее приводятся рекомендации работ в различных условиях.

Сценарии работ​

🛡📈 Улучшает

В целях повышения эффективности тестирования рекомендуется придерживаться следующих практик:

При разработке без API​

Если при старте работ нет готового API, рекомендуется:

  1. Согласовать контракты с backend разработчиком
  2. По согласованным контрактам реализовать заглушки репозиториев в externals
  3. Описать storyshots истории согласно требованиям
  4. Сгенерировать слепок и сохранить его в эталон
  5. Выполнить интеграцию по факту готовности API
примечание

Чем тоньше слои взаимодействия с сервером (запросы и команды) тем больше FE-разработчик сможет разработать функционала без BE-реализации.

подсказка

Эталонные списки можно использовать как источник документации, например при поиске уже реализованных компонентов в системе.

Внимание

Если по итогам backend реализации контракт был изменён - необходимо скорректировать заглушки и повторить шаги выше.

При разработке с API​

Если при старте работ присутствует готовое API, рекомендуется:

  1. Сформировать контракт исходя из реальных API методов
  2. По существующим контрактам реализовать заглушки репозиториев в externals
  3. Описать storyshots истории согласно требованиям
  4. Сгенерировать слепок и сохранить его в эталон
  5. Выполнить интеграцию с реальным API методом
примечание

Шаги 1 и 2 можно пропустить если заглушки уже были реализованы ранее.

подсказка

Рекомендуется наполнять заглушки данными из макетов, даже если реальные API возвращают не пустую информацию.

При дефекте​

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

Рекомендуется следующий набор действий:

  1. Настроить заглушки. Можно использовать HAR слепок сетевых запросов
  2. Настроить действия. Можно использовать шаги воспроизведения
  3. Написать историю, где дефект воспроизводится
  4. Исправить дефект
  5. Убедиться что в истории дефект больше не воспроизводится
  6. Зафиксировать эталон
  7. Проверить на реальном окружении

Таким образом, данный дефект больше не воспроизведется с данными предусловиями.

подсказка

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

примечание

Стоит понимать, что storyshots не тестирует приложение целиком. Напротив, библиотека выстраивает баланс между поддерживаемостью тестов и той защитой, что они дают. Поэтому, совершенно нормальна ситуация, при которой некоторые дефекты фиксируются без закрытия тестами.

При рефакторинге​

storyshots всячески способствует рефакторингу предоставляя защиту от случайного регресса. Рекомендуется следующий порядок работ:

  1. Определить область действия
  2. Если рефакторинг крупный, разделить его на под-шаги
  3. После каждого шага, запускать тесты в UI режиме
  4. После реализации шага и выполнения тестов выполнять коммит.
  5. Повторить шаги 3 и 4 пока вся работа не будет выполнена

Разделение эталонов​

🛡 Улучшает
📈⚡ Ухудшает

storyshots верифицирует поведение приложения с помощью сравнения слепков его поведений. По большей части это снимки экранов.

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

  • Запросы - подменяется программными средствами
  • Среда исполнения - контролируется в ручную
примечание

Операционная система и даже определённое аппаратное обеспечение влияют на то, какой снимок получится в итоговом результате.

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

scheme

  • Локальный эталон - эталон, уникальный для каждого из разработчиков. Исключается из VCS.
  • Глобальный эталон - общий эталон, использующийся как единый источник истинного поведения. Генерируется на едином сервере.
примечание

Создание глобального эталона выполняется в фоновом режиме. Шаблоны реализации для CI/CD можно посмотреть тут.

В такой схеме, при разработке, предлагается следующий порядок работ:

  • Создается ветка под отдельную задачу
  • Генерируется локальный слепок поведения
  • Разрабатываются истории и создаются новые снимки в локальном эталоне
  • По завершению работ, создается MR
  • В рамках реквеста, выполняется скрипт, создающий глобальный эталон из данной ветки
  • Глобальный эталон добавляется в ветку с помощью коммита автоматически
  • Ревьювер просматривает MR вместе со снимками из глобального эталона
подсказка

Журналы не чуствительны к окружению, поэтому их можно не разделять

Внимание

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