Борьба со сложностью кода UI-тестов

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

Один из способов снижения сложности кода тестов делать все возможное чтобы код был линейным без ветвлений и циклов. Но жизнь вносит свои коррективы. Тестируемые системы становятся все более параметризованным. При необходимости тестировать функционал с разными настройками возникает дилемма нужно ли делать один сценарий, обрабатывающий все варианты настроек, или же несколько более простых сценариев. В первом случае получаем сложный код с ветвлением, а во втором дублирование кода. Например, проверка функционала для организаций с разной системой налогообложения, при котором формы документов будут различаться составом реквизитов.

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

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

Вариант 2. Условие возникает на одном из этапов. Сложный случай и однозначного решения нет. В данном случае оставляем условие, но придерживаемся правила - условие должно быть простым (без И/ИЛИ) и не должно содержать вложенных условий. Если правило соблюсти не получается, тогда скорее всего это попытка "впихнуть невпихуемое" и нужно рассматривать разделение на несколько сценариев.

Рассмотрим пример, в табличной части документа ПТиУ для организации с системой УСН появляется поле "Расходы (НУ)" (картинки ниже). Для сценария, который проверяет заполнение формы документа для всех видов организации, нужно обработать появление этого поля. В таком случае без условия не обойтись. А можно поступить по другому - в одном сценарии проверить заполнение общих полей для всех видов организаций, а в другом сценарии проверить заполнение поля "Расходы (НУ)" во всех документах конфигурации. Таким образом получается исключить условия и упростить код сценария.

Организация с УСН
Организация с ОСНО