Фиче-файл¶

Содержание файла¶

В одном фиче-файлы содержатся сценарии, объединенные некоторой логикой и которые стоит запускать вместе. Это может быть проверка одного пользовательского сценария, проверка одного объекта. Один фиче-файл не должен проверять объекты разных подсистем.
Один фиче-файл проверяет работу под одним пользователем. Если первая часть фиче-файла работает под одним пользователем, а вторая - под другим, то нужно разделить фиче-файл на два.
Имя фиче-файла состоит из цифрового префикса и назначения <Цифра>_<Назначение>.

Например, 000_Подготовка.feature, 006_Установка цен и скидок.feature, 018_Возврат товаров.feature, 999_Завершение.feature.

Цифровой префикс должен быть уникальным и задавать порядок выполнения фиче-файлов.
Фиче-файл должен быть перезапускаемым. Если мы дошли до какого-то момента и остановились с ошибкой, то мы должны суметь после исправления ошибки в конфигураторе максимально быстро добраться до ошибки. То есть запустить тестирование именно с проблемного файла и узнать - ушла ошибка или нет.

Структура файла¶

Файл всегда начинается со спец. строки #language: ru, определяющий язык теста.
Дальше находится область тегов.
- Тег может быть функциональным - определяющем принадлежность к блоку. Например, @scp, @logistic, @init.
- Тег может быть управляющим - в зависимости от настроек определяется, нужно ли запускать этот тест.
- Тег может быть служебным - теги @ignore и @exportscenarios для указания, что этот фиче-файл является "экспортным" и в нем лежат экспортные сценарии.
Поле функционал определяет назначение и будет видно в отчетах по запуску. По нему нужно суметь легко и быстро найти фиче-файл. В поле функционал должно быть <Цифровой адрес><Имя блока><Назначение>. Цифровой адрес формируется из цифровых префиксов по иерархии. Например,
```
Функционал: 01. Разруб. Установка функциональных опций
```
Тут 01 - цифровой префикс файла. Разруб - имя блока. Далее - назначение.
Контекст - опциональный блок файла. В блоке Контекст указываются шаги, которые должны быть выполнены перед каждым сценарием. Обычно таких шагов нет. Подключать тест-клиент нужно первым сценарием, а закрывать все окна - последним.
Имя сценария должно быть уникально в рамках каталога всех тестов. Когда сценарий падает - нужно иметь возможность по имени найти что это за сценарий.
Имя сценария формируется аналогично функционалу <Цифровой адрес><Имя блока><Назначение>, только цифровой адрес дополняется номером сценария. Например,
```
Сценарий: 003.1. SCP. АРМ планирования потребностей. Оптимистичный сценарий.
```
Если сценариев много, то их следует группировать и разделять комментариями. Особенно актуально для экспортных сценариев. Ну или разносить в разные фиче-файлы. Большие фиче-файлы сложнее дорабатывать, искать там ошибки и поддерживать, чем маленькие.
```
# Пример комментария
```

Сценарии¶

Каждый фиче-файл должен выполнятся под тем пользователем, под который реализован функционал. Создает пользователей и настраивает систему администратор, заводит номенклатуру пользователь с правами изменения НСИ, планирует пользователь с правами планирования, выполняет задания пользователь с правами рабочего. Если все сценарии выполнять под администратором - их проще написать, но ошибки с ограничением прав пройдут мимо.
Первый сценарий в фиче-файле готовит нужные данные для остальных сценариев этой фичи. Подключает нужный тест-клиент, заполняет переменные, переключает ФО итп.
Последний сценарий в фиче-файле прибирает после выполнения сценариев. Восстанавливает ФО, закрывает все окна, закрывает тест-клиент, если он больше не нужен.
Подход "Given-When-Then". В фиче-файле можно выделить 3 группы сценариев:
- Given - подготовка данных. НСИ, документы, которые понядобятся.
- When - действие над данными. Непосредственное взаимодействие с в проверяемыми объектами.
- Then - проверка результата. Проверка отчетом, что все отработало правильно.
Этот же подход нужно применять на уровне сценария. Например, при проверке документа: - Given - подготовка данных. Ввод данных в документ. - When - действие над данными. Выполнение действий с документом - заполнение ТЧ через подбор, ввод на основании, изменение реквизитов, которые влияют на другие поля, проведение. - Then - проверка результата. Проверка движений, проверка всех элементов формы, что они заполнены так, как ожидалось.

Группируйте шаги внутри сценария. Если очень хочется написать комментарий к блоку шагов, чтобы пояснить - что же тут происходит. Значит тут нужна группировка. Группировка это произвольная строка, где подчиненные шаги имеют отступ. Если нет вложенных шагов с отступом, то эта произвольная строка начинает трактоваться как шаг. Группировки следует начинать с *, чтобы легче определять, что это группировка. Например,

Дано Я разворачиваю панель отборов
* Закупка
    И из выпадающего списка 'Тип обеспечения' я выбираю точное значение 'Закупка'
    Тогда таблица "Список" стала равной:
        | 'Наименование'          | 'Тип обеспечения' |
        | 'Закупка у конкурентов' | 'Закупка'         |
    Тогда элемент формы 'Тип обеспечения' стал равен 'Закупка'
* Производство
    И из выпадающего списка 'Тип обеспечения' я выбираю точное значение 'Производство'
    Тогда таблица "Список" стала равной:
        | 'Наименование' | 'Тип обеспечения' |
        | 'Кулинария'    | 'Производство'    |
        | 'Разруб'       | 'Производство'    |
        | 'Фарш'         | 'Производство'    |
    Тогда элемент формы 'Тип обеспечения' стал равен 'Производство'
* Перемещение
    И из выпадающего списка 'Тип обеспечения' я выбираю точное значение 'Перемещение'
    Тогда таблица "Список" стала равной:
        | 'Наименование'          | 'Тип обеспечения' |
        | 'Кулинария->Основной'   | 'Перемещение'     |
        | 'Переработка->Основной' | 'Перемещение'     |
    Тогда элемент формы 'Тип обеспечения' стал равен 'Перемещение'

Комментарии тоже нужно писать. Комментарии в фиче-файлы начинаются с #
```
# Пример комментария
```

Последнее обновление: September 30, 2021