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

В этой части мы углубимся в возможности Kotest:

• покажу все варианты группировки тесты
• расскажу про последовательность выполнения тестов и спецификаций
• изучим возможности параллельного запуска
• настроим таймауты на выполнение тестов
• проговорим про ожидания и Flaky-тесты
• рассмотрим использование Фабрик тестов
• и напоследок исследуем тему Property Testing

Все части руководства:

• Часть 1. Kotest: Начало

О себе

Я являюсь QA Лидом на одном из проектов Мир Plat.Form (НСПК). Проект зародился около года назад и уже вырос до четырех команд, где трудится в общей сложности около 10 разработчиков в тестировании (SDET), без учета остальных участников в лице аналитиков, разработчиков и технологов.
Наша задача автоматизировать функциональные тесты на уровне отдельных сервисов, интеграций между ними и E2E до попадания функционала в master всего порядка 30 микро-сервисов. Взаимодействие между сервисами Kafka, внешний API REST, а также 2 фронтовых Web приложения.
Разработка самой системы и тестов ведется на языке Kotlin, а движок для тестов был выбран Kotest.

В данной статье и в остальных публикациях серии я максимально подробно рассказываю о тестовом Движке и вспомогательных технологиях в формате Руководства/Tutorial.

Мотивация и цели

На основе первой части руководства можно вполне успешно создавать сценарии, расширять покрытие. Но с увеличением кол-ва тестов и функциональности целевого приложения неизбежно растет и сложность тестов.
Чтобы не изобретать "велосипеды" и не добавлять в проект тестов лишние зависимости хороший QA обязан детально знать функционал тестового движка и всех сторонних библиотек.
Это позволит в дальнейшем проектировать простую, масштабируемую и расширяемую архитектуру каркаса и тестов. А также успешно интегрировать популярные библиотеки.

Уже в следующей части я расскажу про интеграцию со сторонними библиотеками:

• Spring Core/Test. Dependencies Injection и конфигурирование профилей для тестов
• Spring Data JPA. Работа с БД
• TestContainers. Управление Docker контейнерами
• Allure. Отчетность
• Awaitility. Ожидания

Группировка тестов

В публикации много примеров с пояснениями двух видов: комментарии в коде либо объяснения вне блока кода со ссылками на конкретные места примера.
Куски кода больше половины стандартного экрана скрыты спойлером.
Рассматриваемая версия Kotest 4.3.2

Рекомендую на самых ранних стадиях развития проекта с тестами продумать группировку тестов. Самые базовые критерии группировки, которые первыми приходят на ум:

1. По уровню. Модульные -> На один сервис (в контексте микро-сервисов) -> Интеграционные -> E2E

   
   

2. По платформе. Windows\Linux\MacOS | Desktop\Web\IOS\Android

   
   

3. По функциональности. Frontend\Backend В контексте целевого приложения: Авторизация\Администрирование\Отчетность...

   
   

4. По релизам. Sprint-1\Sprint-2 1.0.0\2.0.0

   
   

Далее описание реализации группировки в Kotest

Теги

Для группировки тестов используются теги объекты класса abstract class io.kotest.core.Tag. Есть несколько вариантов декларирования меток:

• расширить класс Tag, тогда в качестве имени метки будет использовано simpleName расширяющего класса, либо переопределенное свойство name.
• использовать объект класса io.kotest.core.NamedTag, где имя метки передается в конструкторе.
• создать String константу и использовать в аннотации @io.kotest.core.annotation.Tags, однако в прошлых версиях Kotest эта аннотация принимала тип KClass<T> класса тегов, а сейчас String имя тега.

Ниже представлены все варианты декларирования тегов:

/** * TAG for annotation @Tag only. */const val LINUX_TAG = "Linux"/** * Name will be class simple name=Windows */object Windows : Tag()/** * Override name to Linux. */object LinuxTag : Tag() {    override val name: String = LINUX_TAG}/** * Create [NamedTag] object with name by constructor. * Substitute deprecated [io.kotest.core.StringTag] */val regressTag = NamedTag("regress")

Применить тег к тесту можно несколькими путями:

• через аннотацию @Tags на классе спецификации
• extension функцию String.config в тесте или контейнере теста
• переопределив метод tags(): Set<Tag> у спецификации

Однако, последний вариант я не рекомендую, т.к. тестовому движку для получения тега и проверки придется создать экземпляр класса Spec и выполнить init блок, а еще выполнить все инъекции зависимостей, если используется Dependency injection в конструкторе.

Пример с 2-мя классами спецификаций:

@Tags(LINUX_TAG) // Аннотацияclass LinuxSpec : FreeSpec() {    init {        "1-Test for Linux" { }                                        /* конфигурация теста String.config */        "2-Test for Linux and Regress only".config(tags = setOf(regressTag)) { }    }}class WindowsSpec : FreeSpec() {    /** Override tags method */    override fun tags(): Set<Tag> = setOf(Windows) // переопределение метода    init {        "Test for Windows" { }    }}

Остается задать выражение тегов для запуска ожидаемого набора тестов через системную переменную -Dkotest.tags=<выражение для выборки тестов по тегам>.
В выражении можно использовать ограниченный набор операторов: (, ), |, &

Теги чувствительны к регистру

Привожу несколько вариантов запуска в виде Gradle task

// Используется встроенный в Gradle фильтр тестов по пакетам без фильтрации теговtask gradleBuildInFilterTest(type: Test) {    group "test"    useJUnitPlatform()    systemProperties = System.properties    filter { includeTestsMatching("ru.iopump.qa.sample.tag.*") }}// Запустить только тест с тегами regress (в тесте) и Linux (в аннотации спецификации) в LinuxSpectask linuxWithRegressOnlyTest(type: Test) {    group "test"    useJUnitPlatform()    systemProperties = System.properties + ["kotest.tags": "Linux & regress"]}// Запустить 2 теста с тегом Linux (в аннотации спецификации) в LinuxSpectask linuxAllTest(type: Test) {    group "test"    useJUnitPlatform()    systemProperties = System.properties + ["kotest.tags": "Linux"]}// Исключить из запуска тесты с тегом Linux, а также Windows. То есть запуститься 0 тестов task noTest(type: Test) {    group "test"    useJUnitPlatform()    systemProperties = System.properties + ["kotest.tags": "!Linux & !Windows"]}// Запустить тесты, у которых имеется тег Linux либо Windows. То есть все тестыtask linuxAndWindowsTest(type: Test) {    group "test"    useJUnitPlatform()    systemProperties = System.properties + ["kotest.tags": "Linux | Windows"]}

Обращаю внимание на 2 момента:

• Kotest запускается через Junit5 Runner, поэтому декларирован useJUnitPlatform()
• Gradle не копирует системные переменные в тест, поэтому необходимо явно указать systemProperties = System.properties

Условный запуск

В коде спецификации можно задать динамические правила включения/выключения тестов двумя путями:

• на уровне спецификации через аннотацию @io.kotest.core.annotation.EnabledIf и реализацию интерфейса EnabledCondition
• на уровне теста через расширение String.config(enabledIf = (TestCase) -> Boolean)
  Вот пример:

/** [io.kotest.core.annotation.EnabledIf] annotation with [io.kotest.core.annotation.EnabledCondition] */@EnabledIf(OnCICondition::class) // Аннотация принимает класс с логикой включениеclass CIOnlySpec : FreeSpec() {    init {                            /* Логика включения передается в конфигурацию теста */        "Test for Jenkins".config(enabledIf = jenkinsTestCase) { }    }}/** typealias EnabledIf = (TestCase) -> Boolean */val jenkinsTestCase: io.kotest.core.test.EnabledIf = { testCase: TestCase -> testCase.displayName.contains("Jenkins") }/** Separate class implementation [io.kotest.core.annotation.EnabledCondition] */class OnCICondition : EnabledCondition {    override fun enabled(specKlass: KClass<out Spec>) = System.getProperty("CI") == "true"}

Тест запустится, если:

1. Среди системных переменных будет переменная CI=true
2. В отображаемом имени TestCase встретится строка Jenkins

Функционал не самый используемый.
Есть более простой, но менее гибкий вариант через параметр enabled.
Например: "My test".config(enabled = System.getProperty("CI") == "true") { }

Последовательность выполнения

Уровень спецификации

По-умолчанию спецификации выполняются в порядке загрузки классов JVM. Это зависит от платформы, но скорее всего порядок будет алфавитный. Есть возможность задать порядок через конфигурацию уровня проекта используя enum io.kotest.core.spec.SpecExecutionOrder

object ProjectConfig : AbstractProjectConfig() {    override val specExecutionOrder = SpecExecutionOrder.Annotated}

• SpecExecutionOrder.Undefined. Используется по-умолчанию и зависит от загрузки классов на платформе.
• SpecExecutionOrder.Lexicographic. В алфавитном порядке имен классов спецификаций
• SpecExecutionOrder.Random. В случайном порядке.
• SpecExecutionOrder.Annotated. На основе аннотаций @Order над классами спецификаций с номерным аргументом. Меньше номер раньше выполнение. Не помеченные выполняются в конце по стратегии Undefined
• SpecExecutionOrder.FailureFirst. Новая стратегия. Сначала выполняет упавшие в предыдущем прогоне тесты, а остальные спецификации по стратегии Lexicographic

Для использования FailureFirst необходимо включить сохранение результатов прогона в конфигурации проекта. По-умолчанию результаты сохраняются по пути на файловой системе ./.kotest/spec_failures в директории проекта.

object ProjectConfig : AbstractProjectConfig() {    override val specExecutionOrder = SpecExecutionOrder.FailureFirst    /**     * Save execution results to file for [SpecExecutionOrder.FailureFirst] strategy.     * File location: [io.kotest.core.config.Configuration.specFailureFilePath] = "./.kotest/spec_failures"     */    override val writeSpecFailureFile = true}

Привожу пример использования стратегии Annotated:

object ProjectConfig : AbstractProjectConfig() {    override val specExecutionOrder = SpecExecutionOrder.Annotated}@Order(Int.MIN_VALUE) // Аннотация на классеclass FirstSpec : FreeSpec() {    init {        "FirstSpec-Test" { }    }}@Order(Int.MIN_VALUE + 1) // Аннотация на классеclass SecondSpec : FreeSpec() {    init {        "SecondSpec-Test" { }    }}@Order(Int.MAX_VALUE) // Аннотация на классеclass LastSpec : FreeSpec() {    init {        "LastSpec-Test" { }    }}

Порядок выполнения будет такой: FirstSpec -> SecondSpec -> LastSpec. Чем больше число в @Order тем позже выполнение.

Уровень тестов

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

Для всего проекта можно настроить последовательность в конфигурации проекта:

object ProjectConfig : AbstractProjectConfig() {    override val testCaseOrder: TestCaseOrder = TestCaseOrder.Random}

В рамках одного класса через переопределение метода testCaseOrder:

class TestOrderingSpec : FreeSpec() {    override fun testCaseOrder(): TestCaseOrder = TestCaseOrder.Lexicographic}

Параллельность

Очень интересная и сложная тема, как в контексте разработки, так и в контексте тестирования.
Рекомендую ознакомиться с книгой Java Concurrency in Practice она как раз недавно появилась на русском языке.
Основой для принятия решения запуска тестов параллельно служит свойство теста быть независимым в контексте Фреймворка тестов и тестируемой системы.
Недостаточно обеспечить очистку состояния тестируемой системы, в которое она перешла после выполнения теста,- необходимо обеспечить неизменное состояние во время выполнения теста, либо гарантию, что изменение состояния не имеет инвариантов с другими воздействиями на систему в других тестах.

Для гарантии изолированности необходимо:

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

Есть системы, которые потенциально независимо обрабатывают запросы или сессии, можно положиться на это, однако 100% гарантии никто не даст.
Тест может воздействовать на систему в обход публичного API (например что-то записать в БД напрямую), что также может нарушить изоляцию.

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

Уровень тестов

Можно задать кол-во потоков для тестов в рамках одного класса спецификации переопределив метод fun threads()

Пример спецификации с 2-мя тестами и 2-мя потоками:

class OneParallelOnTestLevelSpec : FreeSpec() {    private companion object {        private val log = LoggerFactory.getLogger(OneParallelOnTestLevelSpec::class.java)    }    override fun threads(): Int = 2    init {        "parallel on test level 1" {            log.info("test 1 started")            delay(500)            log.info("test 1 finished")        }        "parallel on test level 2" {            log.info("test 2 started")            delay(1000)            log.info("test 2 finished")        }    }}

Запустим с помощью gradle задачи:

task parallelismTest(type: Test) {    group "test"    useJUnitPlatform()    filter { includeTestsMatching("ru.iopump.qa.sample.parallelism.OneParallelOnTestLevelSpec") }}

Имеем вывод:

21:15:44:979 OneParallelOnTestLevelSpec - test 2 started21:15:44:979 OneParallelOnTestLevelSpec - test 1 started21:15:45:490 OneParallelOnTestLevelSpec - test 1 finished21:15:45:990 OneParallelOnTestLevelSpec - test 2 finished

По логу видно, что test 1 и test 2 запустились одновременно в 21:15:44:979 и завершились:
первый в 21:15:45:490, второй через 500мс, все по-плану.

Уровень спецификации

Чтобы запустить классы спецификаций в несколько потоков нужно задать настройки параллельности до их запуска, то есть на уровне конфигурации проекта:

object ProjectConfig : AbstractProjectConfig() {    override val parallelism: Int = 3}

Либо через системную переменную -Dkotest.framework.parallelism=3 или прямо в задаче gradle:

task parallelismTest(type: Test) {    group "test"    useJUnitPlatform()    doFirst { systemProperties = System.properties + ["kotest.framework.parallelism": 3] }    filter { includeTestsMatching("ru.iopump.qa.sample.parallelism.*") }}

Используем одну спецификацию с прошлого раздела OneParallelOnTestLevelSpec и 2 новые, где сами тесты внутри будут выполняться последовательно:

class TwoParallelSpec : FreeSpec() {    private companion object {        private val log = LoggerFactory.getLogger(TwoParallelSpec::class.java)    }    init {        "sequential test 1" {            log.info("test 1 started")            delay(1000)            log.info("test 1 finished")        }        "sequential test 2" {            log.info("test 2 started")            delay(1000)            log.info("test 2 finished")        }    }}class ThreeParallelSpec : FreeSpec() {    private companion object {        private val log = LoggerFactory.getLogger(ThreeParallelSpec::class.java)    }    init {        "sequential test 1" {            log.info("test 1 started")            delay(1000)            log.info("test 1 finished")        }        "sequential test 2" {            log.info("test 2 started")            delay(1000)            log.info("test 2 finished")        }    }}

Все 3 спецификации должны запуститься параллельно, а также тесты в OneParallelOnTestLevelSpec выполняться в своих 2-ух потоках:

21:44:16:216 [kotest-engine-1] CustomKotestExtension - [BEFORE] prepareSpec class ru.iopump.qa.sample.parallelism.ThreeParallelSpec21:44:16:216 [kotest-engine-2] CustomKotestExtension - [BEFORE] prepareSpec class ru.iopump.qa.sample.parallelism.TwoParallelSpec21:44:16:216 [kotest-engine-0] CustomKotestExtension - [BEFORE] prepareSpec class ru.iopump.qa.sample.parallelism.OneParallelOnTestLevelSpec21:44:18:448 [SpecRunner-3] ThreeParallelSpec - test 2 started21:44:18:448 [SpecRunner-6] OneParallelOnTestLevelSpec - test 1 started21:44:18:448 [SpecRunner-5] TwoParallelSpec - test 1 started21:44:18:448 [SpecRunner-4] OneParallelOnTestLevelSpec - test 2 started21:44:18:959 [SpecRunner-6] OneParallelOnTestLevelSpec - test 1 finished21:44:19:465 [SpecRunner-5] TwoParallelSpec - test 1 finished21:44:19:465 [SpecRunner-3] ThreeParallelSpec - test 2 finished21:44:19:465 [SpecRunner-4] OneParallelOnTestLevelSpec - test 2 finished21:44:19:471 [SpecRunner-5] TwoParallelSpec - test 2 started21:44:19:472 [SpecRunner-3] ThreeParallelSpec - test 1 started21:44:20:484 [SpecRunner-3] ThreeParallelSpec - test 1 finished21:44:20:484 [SpecRunner-5] TwoParallelSpec - test 2 finished

По логу видно, что все 3 спецификации прошли за 2 сек это сумма последовательных тестов одной их спецификаций выше, тесты из OneParallelOnTestLevelSpec выполнились еще быстрее.
В выводе я оставил первые три строки, чтобы продемонстрировать имена потоков:

• пул потоков для спецификаций NamedThreadFactory("kotest-engine-%d")
• пул дочерних потоков для тестов NamedThreadFactory("SpecRunner-%d")

Все это запускается с помощью Executors.newFixedThreadPool и особенности работы с корутинами конкретно в этой конфигурации не используются, т.к. suspend функции выполняются через runBlocking:

executor.submit {    runBlocking {        run(testCase)    }}

Подробности реализации в методах io.kotest.engine.KotestEngine.submitBatch и io.kotest.engine.spec.SpecRunner.runParallel

Исключение из параллельного запуска

Если спецификацию по каким-то причинам следует выполнять в единственном потоке, то есть аннотация @DoNotParallelize.
Для отдельного теста на текущий момент подобного не предусмотрено.

Таймауты

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

Привожу пример спецификации со всеми вариантами таймаута:

Для пояснений в коде я буду использовать метки формата /*номер*/ и после примера рассказывать про каждую в виде: номер -

@ExperimentalTimeclass TimeoutSpec : FreeSpec() {    private companion object {        private val log = LoggerFactory.getLogger(TimeoutSpec::class.java)    }    /*1*/override fun timeout(): Long = 2000 // Spec Level timeout for each TestCase not total    /*2*/override fun invocationTimeout(): Long =        2000 // Spec Level invocation timeout for each TestCase invocation not total    init {        /*3*/timeout = 1500 // Spec Level timeout for each TestCase not total        /*4*/invocationTimeout = 1500 // Spec Level invocation timeout for each TestCase invocation not total        "should be invoked 2 times and will be successful at all".config(            /*5*/invocations = 2,            /*6*/invocationTimeout = 550.milliseconds,            /*7*/timeout = 1100.milliseconds        ) {            log.info("test 1")            delay(500)        }        "should be invoked 2 times and every will fail by invocationTimeout".config(            invocations = 2,            invocationTimeout = 400.milliseconds,            timeout = 1050.milliseconds        ) {            log.info("test 2")            delay(500)        }        "should be invoked 2 times and last will fail by total timeout".config(            invocations = 2,            invocationTimeout = 525.milliseconds,            timeout = 1000.milliseconds        ) {            log.info("test 3")            delay(500)        }    }}

Агрегирующего таймаута на всю спецификацию нет. Все варианты устанавливают таймаут только на тест.

5 invocations = 2 В Kotest есть возможность задать ожидаемое кол-во успешных выполнений одного теста, чтобы считать его успешным.
Например, чтобы проверить требование отсутствия состояния в системы, можно выполнить тест несколько раз, если хотя бы одно выполнение будет неуспешным, то тест будет считаться неуспешным. Не путайте с fluky это обратная ситуация.

1 override fun timeout(): Long = 2000 Через переопределение метода. Установить таймаут на тест в мс.

2 override fun invocationTimeout(): Long = 2000 Через переопределение метода. Установить таймаут на один вызов теста в мс (см 5).

3 timeout = 1500 Через свойство. Установить таймаут на тест в мс и переписать 1

4 invocationTimeout = 1500 Через свойство. Установить таймаут на один вызов теста в мс и переписать 2 (см 5).

6 invocationTimeout = 550.milliseconds Через метод конфигурации теста. Установить таймаут на тест в kotlin.time.Duration и переписать 3.

7 timeout = 1100.milliseconds Через метод конфигурации теста. Установить таймаут на один вызов теста в kotlin.time.Duration и переписать 4 (см 5).

kotlin.time.Duration имеет статус Experimental и при использовании требует установки @ExperimentalTime над классом спецификации

Разберем вывод запуска TimeoutSpec:

08:23:35:183 TimeoutSpec - test 108:23:35:698 TimeoutSpec - test 108:23:36:212 CustomKotestExtension - [AFTER] afterTest. Test case duration: 1047 ms08:23:36:217 TimeoutSpec - test 2Test did not complete within 400msTimeoutException(duration=400)08:23:36:625 TimeoutSpec - test 308:23:37:141 TimeoutSpec - test 3Test did not complete within 1000msTimeoutException(duration=1000)

Первый тест прошел успешно 2 раза, каждое выполнение уместилось invocationTimeout и весь тест в timeout
Второй тест упал на первом выполнении и не стал далее выполняться по invocationTimeout TimeoutException(duration=400)
Третий тест упал на втором выполнении по своему timeout TimeoutException(duration=1000)

Все таймауты можно задать в глобальной конфигурации и через системные переменные:

@ExperimentalTimeobject ProjectConfig : AbstractProjectConfig() {    /** -Dkotest.framework.timeout in ms */    override val timeout = 60.seconds    /** -Dkotest.framework.invocation.timeout in ms */    override val invocationTimeout: Long = 10_000}

Встроенные ожидания

Во время тестов система реагирует на наши действия не мгновенно, особенно в E2E. Поэтому для всех проверок результатов взаимодействия с системой необходимо использовать ожидание. Приведу неполный список основных:

• ожидание HTTP ответа (уже есть на уровне HTTP клиента, достаточно только указать таймаут)
• ожидание появления запроса на заглушке
• ожидание появления/изменения записи в БД
• ожидание сообщения в очереди
• ожидание реакции UI (для Web реализовано в Selenide)
• ожидание письма на SMTP сервере

Если не понятно, почему нужно ждать в заглушке или в БД, отвечу в комментариях или сделаю отдельную публикацию

Есть отличная утилита для тонкой настройки ожиданий: Awaitility о ней пойдет речь в будущих частях. Но Kotest из коробки предоставляет простой функционал ожиданий.
В документации движка этот раздел называется Non-deterministic Testing.

Eventually

Подождать пока блок кода пройдет без Исключений, то есть успешно, в случае неуспеха повторять блок еще раз.
Функция из пакета io.kotest.assertions.timing: suspend fun <T, E : Throwable> eventually(duration: Duration, poll: Duration, exceptionClass: KClass<E>, f: suspend () -> T): T

f это блок кода, который может выбросить Исключение и этот метод будет его перезапускать, пока не выполнит успешно либо не пройдет таймаут duration.
poll это промежуток бездействия между попытками выполнения.
exceptionClass класс исключения по которому нужно попытаться еще раз.
Если есть уверенность, что когда код выбрасывает IllegalStateException, то нужно пробовать еще раз, но если, класс исключения другой, то успешно код точно никогда не выполниться и пытаться еще раз выполнить код не нужно, тогда указываем конкретный класс IllegalStateException::class.

Continually

Выполнять переданный блок в цикле, пока не закончится выделенное время либо пока код не выбросит Исключение.
Функция из пакета io.kotest.assertions.timing: suspend fun <T> continually(duration: Duration, poll: Duration, f: suspend () -> T): T?

f блок кода, который будет запускаться в цикле пока не пройдет таймаут duration либо не будет выброшено Исключение.
poll промежуток бездействия между попытками выполнения

Рассмотрим пример из четырех тестов (2 eventually + 2 continually)

@ExperimentalTimeclass WaitSpec : FreeSpec() {    private companion object {        private val log = LoggerFactory.getLogger(WaitSpec::class.java)    }    /*1*/    private lateinit var tries: Iterator<Boolean>    private lateinit var counter: AtomicInteger    private val num: Int get() = counter.incrementAndGet()    init {        /*2*/        beforeTest {            tries = listOf(true, true, false).iterator()            counter = AtomicInteger()        }        "eventually waiting should be success" {            /*3*/eventually(200.milliseconds, 50.milliseconds, IllegalStateException::class) {            log.info("Try #$num")            if (tries.next()) /*4*/ throw IllegalStateException("Try #$counter")        }        }        "eventually waiting should be failed on second try" {            /*5*/shouldThrow<AssertionError> {            eventually(/*6*/100.milliseconds, 50.milliseconds, IllegalStateException::class) {                log.info("Try #$num")                if (tries.next()) throw IllegalStateException("Try #$counter")            }        }.toString().also(log::error)        }        "continually waiting should be success" - {            /*7*/continually(200.milliseconds, 50.milliseconds) {            log.info("Try #$num")        }        }        "continually waiting should be failed on third try" {            /*8*/shouldThrow<IllegalStateException> {            continually(200.milliseconds, 50.milliseconds) {                log.info("Try #$num")                if (tries.next()) throw IllegalStateException("Try #$counter")            }        }.toString().also(log::error)        }    }}

1 Блок с полями для подсчета попыток и описания итератора из трех элементов

2 Перед каждым тестовым контейнером сбрасывать счетчики

3 Вызывается функция eventually, которая завершится успешно. Общий таймаут 200 мс, перерыв между попытками 50 мс, игнорировать исключение IllegalStateException

4 Первые две итерации выбрасывают IllegalStateException, а 3-я завершается успешно.

5 Ожидается, что eventually закончится неуспешно и выполняется проверка выброшенного исключения. При неудаче eventually
выбрасывает AssertionError с информацией о причине неудачи и настройках.

6 таймаута 100 мс и перерыв между попытками 50 мс, позволяют выполнить только 2 неудачный попытки, в итоге ожидание завершается неуспешно

7 continually выполнит 4 попытки, все из которых будут успешные и само ожидание завершится успехом

8 Ожидается, что continually закончится неуспешно и выполняется проверка выброшенного исключения. При неудаче continually
перебрасывает последнее Исключение от кода внутри, то есть IllegalStateException, чем отличается от eventually

/////////////////////////////////////////////////////////////////// 1 ////////////////////////////////////////////////////////////////////////21:12:14:796 INFO CustomKotestExtension - [BEFORE] test eventually waiting should be success21:12:14:812 INFO WaitSpec - Try #121:12:14:875 INFO WaitSpec - Try #221:12:14:940 INFO WaitSpec - Try #3/////////////////////////////////////////////////////////////////// 2 ////////////////////////////////////////////////////////////////////////21:12:14:940 INFO CustomKotestExtension - [BEFORE] test eventually waiting should be failed on second try21:12:14:956 INFO WaitSpec - Try #121:12:15:018 INFO WaitSpec - Try #2/* Сообщение в ошибке содержит информацию о настройках ожидания */21:12:15:081 ERROR WaitSpec - java.lang.AssertionError: Eventually block failed after 100ms; attempted 2 time(s); 50.0ms delay between attempts/* Сообщение в ошибке содержит первое выброшенное кодом Исключение и последнее */ The first error was caused by: Try #1java.lang.IllegalStateException: Try #1The last error was caused by: Try #2java.lang.IllegalStateException: Try #2//////////////////////////////////////////////////////////////////// 3 ///////////////////////////////////////////////////////////////////////21:12:15:081 INFO CustomKotestExtension - [BEFORE] test continually waiting should be success21:12:15:081 INFO WaitSpec - Try #121:12:15:159 INFO WaitSpec - Try #221:12:15:221 INFO WaitSpec - Try #321:12:15:284 INFO WaitSpec - Try #4///////////////////////////////////////////////////////////////////// 4 //////////////////////////////////////////////////////////////////////21:12:15:346 INFO CustomKotestExtension - [BEFORE] test continually waiting should be failed on third try21:12:15:346 INFO WaitSpec - Try #121:12:15:409 INFO WaitSpec - Try #221:12:15:469 INFO WaitSpec - Try #3/* Здесь выбрасывается Исключение из выполняемого блока в continually */21:12:15:469 ERROR WaitSpec - java.lang.IllegalStateException: Try #3

Flaky тесты

Flaky тесты это нестабильные тесты, которые могут случайным образом проходить неудачно. Причин этому крайне много и разбирать мы их конечно же не будем в рамках этой статьи, обсудим варианты перезапуска подобных тестов. Можно выделить несколько уровней для перезапуска:

• на уровне CI перезапускать всю Задачу прогона тестов, если она неуспешна
• на уровне Gradle сборки, используя плагин test-retry-gradle-plugin или аналог
• на уровне Gradle сборки, с помощью своей реализации, например сохранять упавшие тесты и запускать их в другой задаче

Другие инструменты для сборки Java/Kotlin/Groovy кроме Gradle не рассматриваю

• на уровне тестового движка
• на уровне блоков кода в тесте (см. раздел Встроенные ожидания и retry)

На текущей момент в версии Kotest 4.3.2 нет функционала для перезапуска нестабильных тестов. И не работает интеграция с Gradle плагином test-retry-gradle-plugin.

Есть возможность перезапустить отдельный блок кода. Это особенно актуально для UI тестирования, когда клик на некоторые элементы иногда не срабатывает.
Представьте ситуацию с Dropdown внизу страницы, после скролла происходит клик, далее ожидание раскрытия элементов и клик на элемент списка.
Так вот, независимо от Фронтового фреймворка, иногда клик для раскрытия списка может не сработать и список не появляется, нужно еще раз попробовать начиная с клика.

Можно сделать повтор через try/catch, но лучше использовать
функцию suspend fun <T, E : Throwable> retry(maxRetry: Int, timeout: Duration, delay: Duration = 1.seconds, multiplier: Int = 1, exceptionClass: KClass<E>, f: suspend () -> T)::

// using Selenidedropdown.scrollTo()retry(2, 20.seconds, exceptionClass = Throwable::class) {    dropdown.click()    dropdownItems.find(Condition.text("1")).apply {        click()        should(Condition.disappear)    }}

Действие scrollTo повторять не нужно. После перехода к элементу блок с раскрытием списка и выбором повторить 2 раза, но не дольше 20 сек игнорируя все исключения (или более конкретные).

В Kotest возможно создать свое расширение для перезапуска упавших спецификаций/контейнеров теста/тестов.
В 3 части руководства я покажу как создать самый простой вариант для уровня тестов.
Остальные варианты я планирую реализовать в своем GitHub репозиторие и выпустить в MavenCentral, если к тому моменту разработчик Kotest не добавит поддержку 'из коробки'.

Фабрики тестов

Представим, что в каждом тесте нужно выполнять одни и те же действия для подготовки окружения: наполнять БД, очереди, конфиги на файловой системе.
Для этих действий хочется создать шаблон теста с адекватным именем, возможно с описанием в виде javadoc/kdoc и несколькими аргументами, например именем и паролем тестового пользователя.
В Kotest такой подход называется Test Factories и позволяет вставлять куски тестов в корневой тест.
Это ни функции, ни методы, ни абстракции это параметризованные части теста с той же структурой, что основной тест, но используемые в нескольких местах кода.

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

Очень важно не нарушать читабельность теста использованием шаблонов:

• имя шаблона должно быть понятное и сопровождаться описанием, а так же описанием всех параметров.
• шаблон должен выполнять одну функцию, например настройка БД (принцип единственной ответственности)
• шаблон должен быть описан в BDD стиле
• шаблон не должен быть слишком абстрактным (субъективно)

Теперь к реализации в Kotest. Она очень ограничена, поэтому я приведу пример того, как рекомендует делать шаблоны официальная документация и как это удобнее делать своими силами через scope-функции и функции-расширения.
Пример кода с пояснениями:

class FactorySpec : FreeSpec() {    init {        /*1.1*/include(containerFactory(1, 2, log))        "root container" - {            /*2.1*/containerTemplate()        }    }}/** Kotest factory */fun containerFactory(argument1: Any, argument2: Any, logger: Logger) =    /*1.2*/freeSpec {    beforeContainer { logger.info("This 'beforeContainer' callback located in the test factory") }    "factory container" - {        "factory test with argument1 = $argument1" { }        "factory test with argument2 = $argument2" { }    }}/** Add [TestType.Container] by scope function extension *//*2.2*/suspend inline fun FreeScope.containerTemplate(): Unit {    "template container with FreeScope context" - {        /*2.3*/testCaseTemplate()    }}/** Add [TestType.Test] by scope function extension *//*2.4*/suspend inline fun FreeScope.testCaseTemplate() {    "nested template testcase with FreeScope context" { }}private val log = LoggerFactory.getLogger(FactorySpec::class.java)

TestFactory

1.1 С помощью метода fun include(factory: TestFactory) включаем шаблон теста в спецификацию в качестве самостоятельного теста.

1.2 Определена функция containerFactory, которая возвращает экземпляр TestFactory и принимает несколько параметров. Для создания объекта TestFactory используем функцию fun freeSpec(block: FreeSpecTestFactoryConfiguration.() -> Unit): TestFactory, которая принимает блок тестов и предоставляет контекст FreeSpecTestFactoryConfiguration.
Внутри этого блока пишем тест, как обычно, в BDD силе. Далее с помощью includeшаблон вставляется как обычный контейнер теста.

Для TestFactory выполняются все обратные вызовы, что определены для спецификации, куда встраивается шаблон.
А также доступны все методы для создания обратных вызовов внутри фабрики, например beforeContainer.
У TestFactory есть большие ограничения:

• нельзя вставлять include друг в друга
• встраивать можно только на уровень спецификации, то есть фабрика должна быть полным тестом, а не частью теста.

Шаблоны через scope-функции и функции-расширения.

2.1 Внутри контейнера вызывается пользовательская функция containerTemplate и добавляет к контексту этого контейнера новые шаги теста.

2.2 Функция suspend inline fun FreeScope.containerTemplate(): Unit выполняет свой код в контексте внешнего теста FreeScope и просто изменяет этот контекст, добавляя новый вложенный контейнер.
Функция ничего не возвращает, а именно изменяет (side-effect) переданный контекст. Тесты пишем так, как будто они не в отдельной функции, а в спецификации.
suspend обязателен, т.к. все тесты запускаются в корутине.
inline для скорости, не обязателен. Указывает компилятору на то, что код этой функции нужно просто скопировать вместо вызова, то есть в байт-коде, не будет containerTemplate, а будет вставленный код в спецификации.
FreeScope. внутренности вызываются в контексте этого объекта, в данном случае контейнера

2.3 Внутри шаблона вызывается другой шаблон, который добавлен новые шаги. В реальных тестах так делать не следует

2.4 Функция suspend inline fun FreeScope.testCaseTemplate(): Unit добавляет вложенные шаги теста вместо вызова. Все то же самое, что и 2.2

В итоге имеем следующую структуру теста после выполнения:

Property тестирование

Представим, что мы в 90-х годах на большом и сложном проекте, где критично качество и есть ресурсы на всеобъемлющее тестирование, на всех вариантах тестовых данных и окружений.
В этом случае невозможно использовать ограниченный тестовых набор, если только тип входных данных не ограничен парой вариантов Data-Driver не подходит.
В таких случаях необходимо генерировать тестовые данные случайным образом, либо вообще покрывать абсолютно все возможные значения.
Необходимо не просто уметь генерировать данные, но и легко менять параметры генерации: функции распределения значений, граничные значения и т.п.
Не менее важна возможность повторить последовательность с прошлого прогона, чтобы воспроизвести ошибку. А также требуются инструменты для создания своих генераторов.

Генераторы данных

В Kotest существует 2 типа генераторов данных:

• Arb (Arbitrary Случайный) генерирует бесконечные последовательности из которых по-умолчанию в тесте будет используется 1000 значений
• Exhaustive (Исчерпывающий) служит для полного перебора ограниченного набора значений

Полный список генерируемых типов довольно большой и хорошо описан в официальной документации

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

Приведу несколько примеров генераторов для генерации единичных значений или ограниченного набора значений, которые можно с успехом использовать в Data-Driven тестах:

/** For string generator with leading zero *//*1*/val numberCodepoint: Arb<Codepoint> = Arb.int(0x0030..0x0039)        .map { Codepoint(it) }/** For english string generator *//*2*/val engCodepoint: Arb<Codepoint> = Arb.int('a'.toInt()..'z'.toInt())    .merge(Arb.int('A'.toInt()..'Z'.toInt()))    .map { Codepoint(it) }class GeneratorSpec : FreeSpec() {    init {        /*3*/"random number supported leading zero" {            Arb.string(10, numberCodepoint).next()                .also(::println)        }        /*4*/"random english string" {            Arb.string(10, engCodepoint).orNull(0.5).next()                .also(::println)        }        /*5*/"random russian mobile number" {            Arb.stringPattern("+7\\(\\d{3}\\)\\d{3}-\\d{2}-\\d{2}").next()                .also(::println)        }        /*6*/"exhaustive collection and enum multiply" {            Exhaustive.ints(1..5).times(Exhaustive.enum<Level>()).values                .also(::println)        }        /*7*/"exhaustive collection and enum merge" {            Exhaustive.ints(1..5).merge(Exhaustive.enum<Level>()).values                .also(::println)        }    }}

1 Класс Codepoint задает набор символов в виде кодов Unicode. Этот класс используется в Arb для генерации строк.
В Kotest есть встроенные наборы символов в файле io.kotest.property.arbitrary.codepoints.
В примере определен набор Unicode цифр (такого набор нет среди встроенных). В дальнейших шагах этот набор будет использован для генерации номеров, которые могут начинаться на 0

2 Определен набор букв английского алфавита. Т.к. в Unicode они идут не по порядку, то сначала создается набор малого регистра, потом merge с набором большого регистра.

3 Использование набора символов цифр numberCodepoint для генерации номеров, где возможен 0 в начале типа String, длина 10 символов.

4 Использование набора символов английского алфавит engCodepoint для генерации слов длиной 10 символов. А также с вероятностью 50% вместо строки сгенерируется null метод orNull(0.5)

5 Метод Arb.stringPattern позволяет генерировать строки на основе RegEx паттерна очень полезная функциональность. Реализация на основе Generex. Производительность оставляет желать лучшего и зависит от сложности регулярного выражения.
Для номера телефона генерация происходит в 10 раз медленнее, чем при использовании Arb.string(10,numberCodepoint) с форматированием. У меня 1000 генераций телефона по паттерну -> 294 мс и 1000 генераций телефона из строки цифр с последующим форматированием -> 32 мс.
Замерять удобно методом measureTimeMillis.

6 Exhaustive фактически просто обертка для перечислимых типов и актуальна только в интеграции с Property-тестами, однако также имеет интересные возможности. Здесь происходит умножение набора Int на объекты enum Level и на выходы получается 25 Pair. Если интегрировать в тест, то будет 25 запусков для каждой пары.

7 Exhaustive объединение в одну коллекцию из 10 разнородных элементов вида: [1, ERROR, 2, WARN ...]

Вся функциональность генераторов доступна не только для Property-тестов, но и для простых тестов, где нужны случайные значения тестовых данных.
Для генерации одного значения используется терминальный метод Arb.next

Результаты запуска:

// Test 12198463900// Test 2tcMPeaTeXG// Test 3+7(670)792-05-16// Test 4[(1, ERROR), (1, WARN), (1, INFO), (1, DEBUG), (1, TRACE), (2, ERROR), (2, WARN), (2, INFO), (2, DEBUG), (2, TRACE), (3, ERROR), (3, WARN), (3, INFO), (3, DEBUG), (3, TRACE), (4, ERROR), (4, WARN), (4, INFO), (4, DEBUG), (4, TRACE), (5, ERROR), (5, WARN), (5, INFO), (5, DEBUG), (5, TRACE)]// Test 5[1, ERROR, 2, WARN, 3, INFO, 4, DEBUG, 5, TRACE]

Написание и конфигурирование Property тестов

Kotest предоставляет две функции для запуска Property-тестов, а также их перегруженные вариации:

• suspend inline fun <reified A> forAll(crossinline property: PropertyContext.(A) -> Boolean)
• suspend inline fun <reified A> checkAll(noinline property: suspend PropertyContext.(A) -> Unit)

Отличие между ними заключается в том, что переданный блок в forAll должен возвращать Boolean, а в checkAll все проверки должны быть внутри, что более привычно.

Выполнить 1000 итераций кода со случайным входным числом типа Long:

checkAll<Long> { long: Long ->    val attempt = this.attempts()    println("#$attempt - $long")    long.shouldNotBeNull()}

Обращаю внимание на то, что функциональное выражение в аргументе forAll и checkAll не простое, а с дополнительным контекстом!

suspend PropertyContext.(A) -> Unit имеем аргумент generic типа (в примере это long: Long), но также имеем доступ к контексту PropertyContext, через ключевое слово this (для красоты его можно опустить).

val attempt = this.attempts() здесь возвращается кол-во пройденных попыток из PropertyContext, но там есть и другие полезные методы.

Пользовательские генераторы

У обоих видов генераторов (Arb и Exhaustive) есть терминальные методы forAll и checkAll, которые запускают блок теста, принимающий сгенерированные значения от пользовательских генераторов в качестве аргумента.

Arb

Задача: Рассмотрим написание Property-теста на примере основной теоремы арифметики: каждое натуральное число можно представить в виде произведения простых чисел. Также это называется факторизация.
Допустим имеется реализованный на Kotlin алгоритм разложения и его необходимо протестировать на достаточном наборе данных.
Код алгоритма можно найти в примерах

Тестовый сценарий: сгенерированное число, разложить с помощью алгоритма на простые множители и проверить, что полученные множители простые и их произведение равно исходному числу тем самым мы проверим реализацию алгоритма.
Очевидно, что одного прогона недостаточно и 10 прогонов недостаточно, как минимум нужно прогнать тест на 1000 случайных величин, а может и больше.

Параметры генератора данных: Кол-во = 1000. Сгенерированное число должно быть больше 1. В сгенерированной последовательности первые два числа должны быть граничные: 2 и 2147483647.

"Basic theorem of arithmetic. Any number can be factorized to list of prime" {    /*1*/Arb.int(2..Int.MAX_VALUE).withEdgecases(2, Int.MAX_VALUE).forAll(1000) { number ->    val primeFactors = number.primeFactors    println("#${attempts()} Source number '$number' = $primeFactors")    /*2*/primeFactors.all(Int::isPrime) && primeFactors.reduce(Int::times) == number}    /*3*/Arb.int(2..Int.MAX_VALUE).checkAll(1000) { number ->    val primeFactors = number.primeFactors    println("#${attempts()} Source number '$number' = $primeFactors")    /*4*/primeFactors.onEach { it.isPrime.shouldBeTrue() }.reduce(Int::times) shouldBe number}}

1 создается генератор на 1000 итераций, множество значений от 2 до Int.MAX_VALUE включительно, отдельным методом withEdgecasesнеобходимо явно указать 2 и Int.MAX_VALUE граничными значениями.
Методом forAll запускаем тестирование, выходной результат блока теста Boolean. AssertionError Движок выбросит за нас, если будет результат false.

2 метод all принимает ссылку на метод и проверяет, что каждый множитель простой, метод reduce выполняет умножение, а также выполняется конъюнкцию двух проверок.

3 все абсолютно аналогично 1. Отличие только в том, что блок кода не должен возвращать Boolean и используются стандартные Assertions, как в обычном тесте.

4 вместо логических операций используем проверки Kotest

Exhaustive

Для исчерпывающего тестирования все аналогично Arb подходу.

Допустим, реализован метод, который в зависимости от enum UUIDVersion генерирует указанный тип UUID. А также же метод должен принимать null и генерировать UUID типа UUIDVersion.ANY.
Сигнатура: fun UUIDVersion?.generateUuid(): UUID

Чтобы проверить этот функционал, нужно перебрать абсолютно все значения UUIDVersion + null.
Не имея знаний о возможностях Exhaustive можно просто перебрать данные в цикле. Однако Exhaustive упрощает и без того несложную задачу:

"UUIDVersion should be matched with regexp" {    /*1*/Exhaustive.enum<UUIDVersion>().andNull().checkAll { uuidVersion ->    /*2*/uuidVersion.generateUuid().toString()    /*3*/.shouldBeUUID(uuidVersion ?: UUIDVersion.ANY)    .also { println("${attempts()} $uuidVersion: $it") }}}

1 reified функция Exhaustive.enum создаст последовательность всех значений UUIDVersion и добавит null, а далее будет вызван Property-тест

2 вызов тестируемой функции-расширения для генерации UUID

3 встроенная в Kotest проверка на соответствие UUID регулярному выражению

Генераторы по-умолчанию

Если использовать функции forAll и checkAll без явного указания генератора типа Arb или Exhaustive, то будет использоваться генератор по-умолчанию в зависимости от Generic-типа.
Например для forAll<String>{ } будет использован генератор Arb.string(). Вот полный набор из внутренностей Kotest:

fun <A> defaultForClass(kClass: KClass<*>): Arb<A>? {    return when (kClass.bestName()) {        "java.lang.String", "kotlin.String", "String" -> Arb.string() as Arb<A>        "java.lang.Character", "kotlin.Char", "Char" -> Arb.char() as Arb<A>        "java.lang.Long", "kotlin.Long", "Long" -> Arb.long() as Arb<A>        "java.lang.Integer", "kotlin.Int", "Int" -> Arb.int() as Arb<A>        "java.lang.Short", "kotlin.Short", "Short" -> Arb.short() as Arb<A>        "java.lang.Byte", "kotlin.Byte", "Byte" -> Arb.byte() as Arb<A>        "java.lang.Double", "kotlin.Double", "Double" -> Arb.double() as Arb<A>        "java.lang.Float", "kotlin.Float", "Float" -> Arb.float() as Arb<A>        "java.lang.Boolean", "kotlin.Boolean", "Boolean" -> Arb.bool() as Arb<A>        else -> null    }}

Примеры кода:

"check 1000 Long numbers" {    checkAll<Long> { long ->        long.shouldNotBeNull()    }}

Seed

Последнее, что хотелось бы добавить про Property-тестирование и генераторы, это воспроизведение ошибки. Для воспроизведения необходимо повторить тестовые данные. Чтобы повторить последовательность, существует такое понятие, как seed.
Используемый алгоритм псевдо случайных чисел для генерации последовательности использует некий порождающий элемент (seed), и для равных seed получаются равные последовательности.
Cемя изначально генерируется случайно, используя внешний порождающий элемент, например, время либо физический процесс. При возникновении ошибки, Kotest печатает используемое семя, которое можно указать в конфигурации теста и воспроизвести результат.

"print seed on fail" {    /*1*/shouldThrow<AssertionError> {    checkAll<Int> { number ->        println("#${attempts()} $number")        /*2*/number.shouldBeGreaterThanOrEqual(0)    }}./*3*/message.shouldContain("Repeat this test by using seed -?\\d+".toRegex())}"test with seed will generate the same sequence" {    Arb.int().checkAll(/*4*/ PropTestConfig(1234567890)) { number ->        /*5*/if (attempts() == 24) number shouldBe 196548668        if (attempts() == 428) number shouldBe -601350461        if (attempts() == 866) number shouldBe 1742824805    }}

1 Ожидаем исключение AssertionError с семенем.

2 Из 1000 чисел последовательности примерно половина будет точно меньше 0 и проверка должна сработать почти сразу

3 Демонстрация, что сообщение исключения содержит информацию о числе seed

4 Для теста явно указано семя в конструкторе PropTestConfig. Ожидаем, что для этого теста будет генерироваться всегда одна последовательность, независимо от платформы

5 attempts() возвращает номер итерации. Для итераций 24, 428, 866 будут всегда сгенерированы одинаковые числа

Заключение

Во-первых, привожу ссылку на все примеры qa-kotest-articles/kotest-second.

Был рассмотрен практически весь функционал Kotest

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

Ресурсы

Kotlin. Автоматизация тестирования (часть 1). Kotest: Начало

Примеры кода

Официальная документация Kotest

Kotest GitHub

Kotlin Lang

Coroutines Tutorial

Gradle Testing

Если Вы разрабатываете более-менее сложный программный продукт, то Вам должна быть знакома ситуация, когда системные (end-to-end) тесты по тем или иным причинам автоматизировать не удаётся. На это могут быть разные причины, я приведу несколько примеров:

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

Эти и многие другие ситуации приводят к худшему кошмару любого разработчика ручному тестированию. Самое неприятное заключается в том, что нельзя провести тестирование один раз и забыть о нём. Нет, нам приходится перед каждым релизом (а может и чаще) раскатывать виртуалки, устанавливать туда тестируемое приложение и тыкать по кнопкам снова и снова, чтобы убедиться, что мы не словили регрессию.

Если Вы ищете решение этой проблемы то прошу под кат.

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

кликнуть_мышкой_на_кнопке_с_надписью "Сохранить"напечатать_на_клавиатуре "Hello world"дождаться_надписи_на_экране "Готово"

При этом неважно, что именно вы тестируете: XAML-приложение, Qt-приложение, Electron-приложение, веб-страницу или вообще консольное приложение. Вы кликаете по экрану виртуальной машины и набираете текст на клавиатуре, а как приложение устроено внутри это Вас уже совершенно не волнует. Удобно? Конечно!

Одна только загвоздка довольно трудно понять, где на экране виртуалки находится кнопка "Сохранить", и есть ли на экране надпись "Готово". Я думаю, это одна из причин, почему мы не видим на рынке переизбытка инструментов, работающих по описанному принципу.

Однако, в последнее время технологии компьютерного зрения шагнули далеко вперёд. Искусственные нейронные сети успешно справляются с такими сложными задачами, как, например, управление автомобилем. Неужели они не справятся с такой заведомо более простой задачей, как обнаружение элементов GUI на экране виртуальной машины?

Как вы могли уже догадаться, нейросетям такая задача вполне по плечу. Вы можете сами в этом убедится, попробовав в действии новый инструмент для автоматизации системных тестов интерпретатор тестовых сценариев Testo. Интерпретатор Testo позволяет выполнять сценарии, написанные на специализированном языке тестовых сценариев Testo Lang, которые выглядят примерно следующим образом:

mouse click "Сохранить"type "Hello world"wait "Готово"

Это всё, что Вам надо написать на языке Testo Lang чтобы:

1. Кликнуть на надпись на экране "Сохранить";
2. Напечатать на клавиатуре "Hello world";
3. Дождаться появления на экране строки "Готово".

Однако, мне бы не хотелось, чтобы у Вас сложилось ложное впечатление, будто бы Testo это какой-то аналог AutoIt или Sikuli. Нет, это не просто инструмент для автоматизации чего-то-там, это инструмент, заточенный именно под автоматизацию системных тестов. Testo берёт под свой контроль значительное количество задач, которые обычно выполняет тестировщик: определение того, какие тесты пора прогнать заново, подготовку виртуального стенда, составление отчёта о том, какие тесты свалились и в какой момент, и так далее.

Так, с этого момента поподробнее

Итак, мы в Вами говорим именно о системных (end-to-end) тестах. Системные тесты предполагают, что Вы тестируете программу не саму по себе в вакууме, а помещаете её в конкретное окружение и смотрите, как она с этим окружением справится. Под окружением может пониматься что угодно: и версия ОС, и наличие/отсутствие каких-то приложений/драйверов, и взаимодействие по сети, и соединение с Интернетом, и недостаток дискового пространства/оперативной памяти Да и много чего ещё.

Самый удобный способ создать такое окружение для программы это установить тестируемую программу внутрь виртуальной машины. Но виртуальную машину необходимо для начала создать и установить на неё операционную систему. Давайте посмотрим, как с этой задачей справляется платформа Testo. Мы предусмотрели специальные конструкции в языке тестовых сценариев Testo Lang, предназначенные для создания элементов виртуальной инфраструктуры Ваших стендов. Например, следующий сниппет объявляет "пустую" виртуалку:

machine my_super_vm {    ram: 2Gb    cpus: 2    iso: "ubuntu_server.iso"    disk main: {        size: 5Gb    }}

Эта конструкция создаёт виртуальную машину с 2Гб оперативной памяти, 2 ядрами процессора и 5Гб дискового пространства. При запуске такой виртуалки, начнётся процесс установки операционной системы из образа ubuntu_server.iso.

Это может быть несколько непривычно, но мы рассматриваем процесс установки операционной системы как ещё один тест, наравне с теми тестами, в которых проверяется собственно работоспособность Вашей программы. Это утверждение обретёт бОльший смысл, если мы на секунду представим, что мы разрабатываем не программу, а операционную систему. Может быть это какая-то специализированная система, например Alt Linux, а может быть мы разрабатываем игрушечную операционную систему just for fun. В любом случае, тестировать её как-то надо, а платформа Testo подходит для этой цели как нельзя лучше, потому что для неё нет никакой разницы, что мы тестируем: операционную систему или программу.

Так а что же делать с пустой виртуалкой? В качестве примера давайте посмотрим, как мог бы выглядеть тест, написанный на языке Testo Lang и выполняющий установку операционной системы:

test my_super_test {    my_super_vm {        start        wait "Language"        press Enter        wait "Install Ubuntu Server"        press Enter        wait "Choose the language"        press Enter        # И так далее        ...    }}

Здесь мы видим новую конструкцию языка, которая объявляет тест my_super_test. В этом тесте учавствует всего одна виртуалка my_super_vm. Тест начинается с включения виртуальной машины. Затем мы дожидаемся, когда на экране появится надпись "Language" и нажимаем клавишу Enter. Собственно, весь тест будет заключаться в последовательности таких действий: ждём наступления события, затем печатаем что-то на клавиатуре.

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

machine my_super_vm {    ram: 2Gb    cpus: 2    disk main: {        source: "prepared_vm.qcow2"    }}

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

Подготовка виртуалки и установка ОС это конечно всё очень хорошо, но тесты, тесты-то на мою программу где? Хорошо, давайте представим, что мы хотим протестировать инсталлятор нашей супер-программы. Представим также, что мы уже вручную подготовили виртуальную машину с Windows 10 на борту. Для простоты примера предположим, что инсталлятор нашей супер-программы уже скопирован на рабочий стол этой виртуалки. Тогда автотест на установку программы будет выглядеть следующим образом:

machine my_win_vm {    ram: 2Gb    cpus: 2    disk main: {        source: "my_windows_10.qcow2"    }}test my_installer_test {    my_win_vm {        # Запустим виртуальную машину        start        # Дождёмся появления рабочего стола        wait "Корзина"        mouse dclick "my_super_installator"        wait "Добро пожаловать"        mouse click "Далее"        wait "Выберите путь установки"        mouse click "Продолжить"        wait "Успешно" timeout 10m        mouse click "Закрыть"    }}

Правда, просто? А мы только разогреваемся ...

Что за wait такой и как он работает?

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

1. Воздействие на виртуальную машину (mouse move/click, type, press, start/stop, plug flash и много чего ещё);
2. Анализ происходящего на экране (wait).

Так вот, это действие wait и является основным видом визуальных проверок в языке Testo Lang. Действие wait дожидается появления на экране определённых объектов и событий в течение заданного таймаута (по умолчанию одна минута). И если событие не наступило генерируется ошибка (прямо как человек, который ждёт надписи "Успешно" пока у него не кончится, наконец, терпение).

Если мы говорим про поиск текста на экране виртуалки (то бишь на скриншоте), то обычно для этих целей используют какую-нибудь OCR (Optical Character Recognition) систему (например, Tesseract). Однако, это не совсем верный подход. Дело в том, что OCR-системы строятся исходя из двух постулатов:

• предполагается, что мы ничего не знаем о том, какой текст находится на изображении;
• задача системы извлечь из изображения как можно больше информации.

В случае автотестов мы имеем совершенно иную ситуацию:

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

В платформе Testo для реализации этой задачи мы использовали нейросети. На вход нейросетям мы подаём сразу две вещи: скриншот экрана виртуалки и искомый текст. От нейросети требуется сказать только, есть ли что-то похожее на изображении или нет. Например, если мы ищём слово "Hopa", то нам вполне подойдёт как слово, написанное кириллицей, так и слово, написанное латиницей, потому что выглядят они совершенно одинаково.

Такой подход к визуальным проверкам позволил нам добиться приемлемых результатов по точности детекта теста и, в то же время, получить хорошую скорость работы нейросетей даже на CPU. Разумеется, мы не собираемся останавливаться на достигнутом и будем и дальше совершенствовать точность нейросетей, а также добавим возможность нечёткого поиска по картинкам/иконкам.

На одном wait далеко не уедешь

Писать длинные тесты с помощью wait + click довольно муторно, особенно, если нет автоматического рекодера тестов. Тесты на основе визуальных проверок это скорее крайний вариант, когда нет другой возможности протестировать приложение или настроить тестовое окружение. Обычно всё же существует возможность выполнить какие-то проверки путём запуска процессов на гостевой системе, например с помощью bash-скриптов.

Как раз на этот случай мы предусмотрели специальную конструкцию в языке Testo Lang. Для её работы на виртуальной машине должны быть установлены дополнения для гостевых систем, которые постовляются вместе с интерпретатором Testo. После установки гостевых дополнений становится возможным писать такие тесты:

test my_super_test  {        my_super_vm {            exec bash "echo Hello world from bash"            exec python """                print("Hello from python")            """        }}

Если какая-либо команда из bash-скрипта завершится с ошибкой, то и весь тест будет считаться проваленным. Аналогично, если python-скрипт вернёт не ноль, то выполнение теста сразу же завершится.

На самом деле довольно многие тестовые сценарии выглядят следующим образом. Сначала с помощью wait + click на гостевую систему устанавливаются дополнения, а затем проверки сводятся к запуску процессов на виртуалке. Но при этом ничто не мешает в любой момент вернуться к визуальным проверкам. Тут всё зависит от Вас как Вам удобнее, так и делайте.

Кроме того, гостевые дополнения позволяют легко копировать файлы между виртуалкой и хостом:

test copy_demo {        my_super_vm {            copyto "/file/on/host" "/file/on/guest"            copyfrom "/file/on/guest" "/file/on/host"        }}

Да зачем же придумывать целый язык?

Мне кажется, многие читатели сейчас думают: "Ребят, серьёзно? Целый язык? Зачем? Ну напишите Вы библиотеку для питона или для чего ещё. Все разумные люди так делают".

На самом деле, причин для создания собственного языка у нас было много. Вот лишь несколько из них:

1. Мы бы хотели, чтобы у нашего языка был минимальный порог вхождения для людей, не знакомых с программированием;
2. Мы бы хотели избавиться от лишней мишуры, присущей языкам общего назначения, оставив только то, что требуется для автотестов;
3. Некоторые фичи, которые мы запилили в Testo-lang, просто так не воткнешь в библиотеку для Python!

Например, Testo поддерживает кеширование тестов, благодаря чему тесты можно прогонять инкрементально только в случае, когда это необходимо (аналогично инкрементальной компиляции программ).

Допустим, у Вас есть такой тест:

test run_installator {        my_super_vm {            copyto "/path/on/host.msi" "C:\\Users\\Testo\\Desktop\\setup.msi"            mouse dclick "setup"            ...        }}

Допустим, Вы его запустили, и он прогнался успешно. Если Вы тут же запустите его ещё раз он отработает мгновенно! Так а действительно, зачем прогонять тест ещё раз, если:

1. Сам тест не менялся;
2. Сборка Вашего инсталлятора не менялась.

А вот как только Вы соберёте новую сборку своего инсталлятора и запустите тест ещё раз то он запустится заново! Testo отслеживает все внешние файлы, участвующие в тестах, и как только в них что-то меняется, кеш соответствующих тестов сбрасывается. И да, этот механизм полностью прозрачный Вам не надо писать ничего для того, чтобы это работало.

Ух, круто. А что ещё умеет Testo?

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

# Сеть для соединения двух виртуальных машинnetwork net1 {    mode: "internal"}# Сеть для доступа в Итнернетnetwork internet {    mode: "nat"}machine my_super_client {    ...    nic server_side: {        attached_to: "net1"    }    nic internet: {        attached_to: "internet"    }}machine my_super_server {    ...    nic client_side: {        attached_to: "net1"    }}

Хотите добавить в стенд флешку? Нет проблем, пара строк и у Вас есть виртуальная флешка (можно даже скопировать на неё что-нибудь с хоста)

flash my_super_flash {    fs: ntfs    size: 2048Mb    #Папка с хоста, которую надо скопировать    folder: "/path/on/host"}

Хотите написать реально много тестов? Нет проблем, организуйте их в иерархию! Давайте для большей конкретики рассмотрим такой набор тестов:

1. Установка ОС;
2. Установка гостевых дополнений;
3. Копирование и установка тестируемой программы на виртуалку;
4. Тестирование фичи 1;
5. Тестирование фичи 2.

Очевидно, что каждый последующий тест можно запускать только после того, как успешно отработает предыдущий (кроме последних двух, их можно запускать независимо друг от друга). Поэтому мы можем выстроить такое дерево тестов:

На языке Testo Lang это будет выглядеть не сильно сложнее, чем на рисунке:

test install_os {    ...}test install_guest_additions: install_os {    ...}test install_app: install_guest_additions {    ...}test test_feature_1: install_app {    ...}test test_feature_2: install_app {    ...}

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

Если прямо сейчас заново запустить тесты, то они вовсе не прогонятся, так как ничего с момента последнего запуска и не поменялось. Но как только Вы соберёте новый билд своей тестирумой программы, Testo это отловит и инвалидирует кеш 3, 4 и 5 тестов:

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

Простой, но вполне реальный пример

Возможностей Testo может хватить на десяток статей, поэтому нам бы не хотелось сейчас Вам рассказывать про все из них. Давайте лучше притормозим и рассмотрим базовый, но реальный пример с автоматизацией тестирования простенького самописного standalone-приложения MySuperApp.

Это приложение написано на С++ с использованием библиотеки ImGui, у него нет никаких хуков для автоматизации тестирования, но мы всё равно очень хотим на каждую сборку проверять, что оно успешно запускается на Windows 10 и высвечивает нам окошко с надписью "MySuperApp is working!".

Что ж, для начала нам понадобится виртуалка. Для этого примера мы создадим виртуалку на основе уже существующей, вручную подготовленной виртуалки, на которую мы заранее установили Windows 10:

machine my_vm {    cpus: 2    ram: 4Gb    disk main: {        source: "${QEMU_DISK_DIR}/win10.qcow2"    }}

А как нам скопировать на виртуалку сборку с нашей программой? Давайте для этого воспользуемся флешкой!

flash my_super_flash {    fs: "ntfs"    size: 16Mb    folder: "./dist"}

Сборку с нашей программой поместим в каталог "./dist", а Testo позаботится о том, чтобы она оказалась на флешке.

Ну а теперь пишем сам тест!

test launch_my_simple_app {    my_vm {        ...    }}

Так, стоп, а с чего начать? Да всё просто просто записывайте все действия, которые Вы бы проделывали вручную! Для начала виртуалку надо включить.

start

Окей, а дальше? Дальше надо дождаться появления рабочего стола, конечно же:

wait "Recycle Bin" timeout 10m

Вставляем флешку

plug flash my_super_flash

Кликаем по надписи "USB Drive (E:)"

mouse click "USB Drive (E:)"

Открываем файловый менеджер:

mouse click "Open folder to view files"

Дважды кликаем по нашему приложению:

mouse dclick "MySuperApp"

Как же нам понять, что наше приложение успешно запустилось? Ну, мы знаем, что наше приложение при запуске должно высвечивать надпись "hello world". Поэтому если такая надпись появилась на экране, то это с большой долей вероятности свидетельствует о том, что всё хорошо. Это и будет наша основная проверка в тесте:

wait "hello world"

В конце теста не забываем вытащить флешку, и в сумме у нас получается такой скрипт:

test launch_my_simple_app {    my_vm {        start        wait "Recycle Bin" timeout 10m        plug flash my_super_flash        mouse click "USB Drive (E:)"        mouse click "Open folder to view files"        mouse dclick "MySuperApp"        wait "hello world"        unplug flash my_super_flash    }}

Вот собственно и всё, наш первый тест готов. А как его запустить? Да тоже ничего сложного, главное указать путь QEMU_DISK_DIR:

sudo testo run my_script.testo --param QEMU_DISK_DIR /var/lib/libvirt/qemu/images

Мы подготовили небольшой видеоролик, на котором выполняется запуск этого теста:

А теперь, напоследок, давайте попробуем симитировать ситуацию, когда в нашу программу закралась ошибка.

Например, по какому-то нелепому стечению обстоятельств, мы собрали MySuperApp с динамической линковкой стандартной библиотеки С++ вместо статической. Если программа собрана таким образом, то для её работы на гостевой системе должен быть установлен пакет Microsoft Visual C++ Redistributable. А мы разрабатываем standalone-приложение, которое не должно иметь никаких зависимостей. У разработчика на хостовой системе Microsoft Visual C++ Redistributable конечно же установлен, поэтому такую ошибку легко не заметить.

Итак, мы подкладываем в каталог ./dist новую сборку нашего приложения и запускаем тесты заново. Вот что мы увидим:

При этом в выводе интерпретатора Testo будет указано, какой тест свалился и в какой именно строчке тестового сценария это произошло:

Тест свалился, ошибка выловлена!

Итоги

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

Скачать Testo абсолютно бесплатно без регистрации и СМС, а также ознакомиться с документацией можно у нас на сайте https://testo-lang.ru

Посмотреть больше примеров можно на youtube-канале https://www.youtube.com/channel/UC4voSBtFRjRE4V1gzMZoZuA

Я никогда не пользовался Dr. Web. Я понятия не имею, как он устроен. Но это не помешало мне написать для него ряд автотестов (и лишь лень не позволила мне написать ещё сотню других):

1. Тест на установку Dr. Web;
2. Тест на ограничение доступа к съемным устройствам (флешкам);
3. Тест на разграничение доступа к каталогу между программами;
4. Тест на разграничение доступа к каталогу между пользователями системы (родительский контроль).

Такие и многие другие тесты можно клепать как горячие пирожки, и не только применительно к Dr. Web, и не только применительно к антивирусам. В этой статье я расскажу, как это сделать.

Подготовка

Для тестов нам понадобится виртуалка с Windows на борту. Я подготовил её вручную, выполнив на ней следующие манипуляции:

1. Собственно, установил Windows 10 Pro x64;
2. Во время установки создал основного пользователя "testo" в паролем "1111";
3. Включил автологин для этого пользователя;

Для автоматизации тестов я буду использовать платформу Testo. Что это такое и как этим пользоваться можно почитать здесь. Нам же сейчас требуется импортировать готовую виртуалку в автотесты. Сделать это очень просто:

Здесь предполагается, что /path/to/win10.qcow2 это путь к диску той виртуалки, которую я подготовил вручную. На этом подготовка заканчивается, и начинается экшен.

Тест 1 Устанавливаем Dr. Web!

Для начала надо решить вопрос с переносом дистрибутива Dr. Web на виртуальную машину. Сделать это можно (например) с помощью флешки:

Всё, что нам надо сделать это положить установщик Dr. Web в папочку ${DR_WEB_DIR} (точное значение этого параметра мы будем задавать при запуске testo). А Testo само позаботится о том, чтобы этот инсталлятор оказался на флешке.

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

Можно, конечно, запустить инсталлятор прямо отсюда, из самой флешки. Но мы лучше сделаем всё по-честному мы скопируем инсталлятор на рабочий стол и запустим инсталлятор оттуда. Как же нам скопировать файл? А как бы это сделал человек?

Всё, копирование успешно завершено! Теперь можно закрыть окно с флешкой и вытащить её:

Теперь, когда инсталлятор оказался на рабочем столе, нам нужно дважды кликнуть на него чтобы запустить процесс установки. А сама установка сводится к простому прокликиванию кнопок и галочек и не представляет большого интереса:

Завершаем наш тест перезагрузкой. И в конце не забудем проверить, что после перезагрузки на рабочем столе появилась иконка с Dr. Web:

Отличная работа! Мы автоматизировали установку антивируса Dr. Web! Давайте немного передохнём и посмотрим, как это выглядит в динамике:

Переходим к тестированию фич.

Тест 2 Ограничение доступа к флешкам

Первая фича по списку ограничение доступа к флешкам. Для этого спланируем довольно прямолинейный тест:

1. Попробуем вставить флешку и создать там пустой файл должно получиться. Вытащим флешку;
2. Включим блокировку съемных устройств в Dr. Web Security Center;
3. Ещё раз вставим флешку и попробуем удалить созданный файл. Действие должно быть заблокировано.

Создадим себе новую флешку, вставим её в Windows и попробуем создать папку. Что может быть проще?

Создаём новый текстовый файл через контекстное меню проводника:

Отключаем флешку, делаем это безопасно:

Теперь мы убедились, что с флешкой работать можно, а значит можно приступать к её блокировке в центре безопасности Dr. Web. Для этого сначала надо открыть центр безопасности:

Можем заметить, что для открытия любого приложения в Windows нужно выполнить фактически одинаковые действия (кликнуть на строку поиска, дождаться появления окна с популярными приложениями, вбить имя интересующего приложения, дождаться, когда оно появится в списке и, наконец, нажать Enter). Поэтому эту группу действий можно выделить в макрос open_app, в который в качестве параметра будет передаваться имя открываемого приложения:

Этот макрос нам ещё пригодится.

Первое, что мы сделаем, открыв центр безопасности Dr. Web включим возможность вносить изменения:

Теперь немного покликаем по менюшкам и зайдем в меню "Configure device access rules". В этом меню поставим галочку в пункте "Block removable media".

Попробуем открыть флешку теперь:

Вот так потихоньку-полегоньку мы и написали первый тест с тестированием вполне осязаемой фичи в Dr. Web. Настало время передохнуть и помедитировать, глядя на результаты наших трудов:

Тест 3 Разграничение доступа к каталогу между программами

Основная идея этого тесткейса проверить работу Dr. Web при ограничении доступа к определенной папке. Если конкретно, то необходимо защитить папку от каких-либо изменений, но добавить исключение для какой-нибудь сторонней программы. Собственно, сам тест выглядит следующим образом:

1. Установим на ОС стороннюю программу, для которой чуть позже добавим исключение при доступе к защищаемой папке. Сегодня сторонняя программа дня файловый менеджер FreeCommander;
2. Создаем папку с файликом, которую будем защищать всеми силами;
3. Откроем центр безопасности Dr. Web и включим там защиту этой папки;
4. Настроим исключение для FreeCommander;
5. Попробуем удалить файл из защищаемой папки обычным способом (через проводник Windows). Не должно получиться;
6. Попробуем удалить файлик через FreeCommander. Должно получиться.

Ух, много работы. Быстрее начнём быстрее закончим.

Пункт первый, установка FreeCommander не сильно отличается от установки Dr.Web. Обычная рутина: вставили флешку, запустили инсталлятор и так далее. Пропустим это и перейдём сразу к интересному.

Для работы с Dr. Web создадим новый тест dr_web_restrict_program, который будет полагаться на результат работы предыдущего теста win10_install_freecommander.

Начнём тест с создания папки Protected на рабочем столе:

Заходим в папку Protected и создаём там файл my_file.txt, который будет играть роль защищаемого файла:

Ох, надо было бы тоже оформить это в виде макроса, ну да ладно ...

Отлично, теперь надо включить защиту папки. Идём знакомой дорожкой и открываем Dr. Web, не забываем включить режим изменений. После чего переходим в меню "Data Loss Prevention".

Немного поработаем мышкой и добавим нашу папку Protected в список защищаемых:

Ну а теперь надо настроить исключение по доступу к папке для FreeCommander. Ещё немного работы мышкой:

Теперь аккуратно закрываем все окна и пробуем удалить файл "my_file.txt" стандартным способом:

Но ничего не получилось значит Dr. Web действительно отработал! Половина теста позади, но нам ещё надо проверить, что будет работать исключение для FreeCommander. Для этого открываем FreeCommander и переходим в папку Protected:

Ну и попробуем удалить файл my_file.txt:

Исключение для FreeCommander работает!

Отличная работа! Большой и сложный тесткейс и всё автоматизировано. Немного расслабона:

Тест 4 Родительский контроль

Этот последний на сегодня тесткейс мы построим следующим образом:

1. Создадим нового пользователя MySuperUser;
2. Залогинимся под этим пользователем;
3. Создадим файл my_file.txt от имени нового пользователя;
4. Откроем центр безопасности Dr. Web и включим родительский контроль для этого файла;
5. В родительском контроле ограничим права пользователя MySuperUser на им же созданный файл;
6. Попробуем прочитать и удалить файл my_file.txt от имени MySuperUser и посмотрим на результат.

Я не буду приводить здесь сценарий теста. Он строится по тому же принципу, что и предыдущие тесты: активно работаем мышкой и клавиатурой. При этом нам не важно, что мы автоматизируем хоть Dr.Web, хоть создание нового пользователя в Windows. Но давайте всё же посмотрим, как будем выглядеть прогон такого теста:

Заключение

Исходники всех тестов Вы можете посмотреть здесь

Более того, все эти тесты Вы можете прогнать на своей машине. Для этого Вам потребуется интерпретатор тестовых сценариев Testo. Скачать его можно здесь.

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

Тестов много не бывает. И речь идёт не только о наращивании их количества (что само по себе, конечно, тоже хорошо) речь идёт о разнообразии самих видов тестов. Даже не напрягая воображение можно вспомнить несколько способов протестировать ваше приложение: Unit-тесты, интеграционные тесты, API-тесты, системные тесты и это не вспоминая о том, что тесты ещё бывают функциональными, нагрузочными, направленными на отказоустойчивость...

Но с чего же начинать писать тесты для новых проектов? Лично для меня, как для программиста, самый интуитивный ответ это Unit-тесты. Однако опрометчиво накидываться на сочинение Unit-тестов может не только оказаться бесполезым занятием, но даже нанести вред в будущей разработке проекта.

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

А можно всех посмотреть?

Я думаю, многие из вас видели ту или иную версию вот этой картинки:

Существуют различные вариации этой картинки может меняться количество слоёв, их название, состав, но суть остаётся неизменной: тестирование программ можно разбить на несколько уровней, и при этом чем выше мы поднимаемся по этим уровням тем дороже и сложнее становится разработка и проведение тестов и, соответственно, количество тестов на уровне N+1 будет неизменно меньше, чем на уровне N.

Я хочу вкратце пробежаться по этой пирамиде, обрисовав пару мыслей по каждому виду тестов. Если вы и так отлично в этом разбираетесь, то можете сразу пролистать сюда

Unit-тесты

В основе пирамиды лежат Unit-тесты (или, в русском варианте, модульные тесты). Unit-тесты направлены на тестирование небольших модулей программы. Зачастую под модулем понимается отдельный класс или даже функция.

Несколько особенностей Unit-тестов:

1. Подразумевают принцип "белого ящика" то есть эти тесты требуют наличия и понимания исходных кодов программы.
2. Дёшево стоят, можно наклепать тысячи, если не десятки тысяч Unit-тестов.
3. Быстро прогоняются.
4. По своей природе автоматизированы.
5. Позволяют очень точно локализовывать ошибки можно узнать конкретную функцию/класс, которая работает неправильно.
6. Плохо подходят для комплексных проверок.

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

На следующем уровне пирамиды обычно указываются интеграционные тесты. Интеграционные тесты направлены на тестирование больших обособленных блоков программы и их взаимодействие между собой (опционально). Под блоком может пониматься отдельная библиотека с частью функционала программы, или же просто большой обособленный участок кода, который слишком велик для покрытия обычными Unit-тестами. Если же программа не бьётся на обособленные блоки и имеет монолитную архитектуру, то интеграционные тесты могут прогоняться для всей программы целиком, но при этом программа помещается в "вакуум" никак не общается и не взаимодействует с "внешним миром".

Несколько особенностей интеграционных тестов:

1. Всё ещё требуют принцип "белого ящика" тестирование блоков подразумевает понимание интерфейса этих блоков, как минимум. Внутреннее устройство модулей в интеграционном тестировании уже не участвует.
2. Несколько сложнее Unit-тестов, т.к. зачастую блоки требуют много подготовительной работы, прежде чем они смогут "нормально" функционировать.
3. Чуть сложнее поддаются автоматизации всё зависит от конкретного блока и его устройства/назначения.

API-тесты

Также в пирамиде иногда выделяют API-тесты. Иногда их относят к интеграционным, иногда как отдельный уровень, но сути это не меняет. Если какая-то часть программы имеет чётко выраженный и оформленный API, то можно выстроить тесты, "дергая" этот API и сверяя фактический результат с ожидаемым. Часто такое можно встретить в распределённых приложениях.

Сейчас такой вид тестов получил просто огромное распространение за счёт очень большой популярности REST API. Это очень удобный способ связывать клиент-серверные приложения между собой, и поэтому, конечно, создаётся очень заманчивое желание абстрагироваться от клиента и протестировать только серверную составляющую, дергая за "ниточки" API.

Несколько свойств этого вида тестирования:

1. Может рассматриваться как подвид интеграционного тестирования.
2. Требует чётко оформленного и (желательно) документированного API.
3. Чаще всего нормально поддаётся автоматизации. Если речь идёт о популярном виде API (например, REST) то к вашим услугам большое количество готовых открытых и коммерческих инструментов, которые позволяют автоматизировать такие тесты на раз-два. Если же API нетипичное, то может потребоваться разработать собственную утилиту по вызову этого API и проверке результатов. В любом случае, стоимость автоматизации выше, чем у Unit-тестов.
4. Позволяет протестировать очень большие самостоятельные компоненты программы и иногда всю программу в целом.

Тем не менее, нужно заметить, что этот вид тестирования возможен только при наличии у программы (или у её компонентов) чётко сформированного API. Что бывает далеко не всегда (например, по соображениям безопасности, или просто наличие API не предусмотрено архитектурой приложения).

Системные тесты

На вершине пирамиды располагаются системные (или, как их иногда называют, end-to-end) тесты. Иногда на вершине пирамиды указывают UI-тесты, но лично я бы не стал выделять этот вид тестов в отдельный уровень. Впрочем, это лишь дело вкуса, потому что UI-тесты можно считать подмножеством системных тестов.

Системные тесты направлены на тестирование всей программы в целом, с учётом окружения, в которой программе предстоит работать. Это уточнение очень важное, ведь программа редко когда может работать "сама по себе". Программа работает на одном или нескольких (в случае распределенных приложений) конкретных компьютерах. И на разных компьютерах (в разных условиях) тестируемая программа может повести себя по-разному. Например, клиент-серверное приложение может работать замечательно в обычной сети, но при этом может оказаться неработоспособным при наличии между клиентом и сервером маршрутизатора с настроенным NAT.

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

Несколько заметок о системных тестах:

1. Предполагают тестирование по методу "черного ящика". Никаких знаний об исходных кодах или особенностях работы программы только UI-тесты.
2. Наиболее комплексный вид тестирования даже распределенные приложения тестируются вместе, а не по отдельности.
3. Даёт наибольшую степень уверенности, что протестированные фичи действительно будут работать у конечных пользователей.
4. Самый дорогой вид тестов.
5. Долго или очень долго прогоняются.

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

Что ж, ликбез в теорию я заканчиваю, и перехожу к самой интересной части какой вид тестов лучше писать в первую очередь?

Не спешите с Unit-тестами

Я думаю, что рисунок с пирамидой тестов создаёт обманчивое впечатление. Этот рисунок призван лишь продемонстрировать распределение количества тестов по разным уровням в зависимости от их стоимости. Но вместо этого он создаёт ощущение, что тесты более высокого уровня как бы "базируются" на тестах более низкого уровня. И, соответственно, может показаться, что "пока не разберусь с Unit-тестами, об интеграционных и говорить нечего. Ну а до системных хорошо если вообще доберёмся". И я считаю, что это в корне неверная позиция.

Представим ситуацию, что вы разрабатываете совершенно новое приложение. Неважно, как именно вы его разрабатываете на основе четко сформированных требований или же "по наитию". В какой-то момент времени вам (надеюсь) захочется написать тесты. Это может случиться как только у вас получится что-то работающее, или же тесты окажутся вообще вашим самым первым шагом если вы придерживаетесь концепции TDD (Test Driven Development). Неважно когда, но этот момент настанет. И о каких же тестах вы подумаете в первую очередь?

Лично я, как разработчик, всегда думаю в первую очередь о Unit-тестах! А почему бы и нет? Ведь для меня программа это, в первую очередь, исходный код. Если я сам пишу код и знаю, как он работает/должен работать, то для меня самый логичный первый шаг покрыть его тестами. Больше того, я уже знаю, как это делается, я делал это тысячу раз, это зона моего комфорта. Поэтому я с чувством выполнения великой миссии (тесты это же хорошо!) начинаю стандартную возню с Unit-тестами: скачиваю свой любимый фреймворк, продумываю абстрактные классы вместе с интерфейсами, занимаюсь mock-ированием объектов И радуюсь, какой я молодец.

И тут я загоняю себя в две потенциально-опасные ситуации. Посмотрим на первую проблему.

Кто может быть первым кандидатом на Unit-тесты? Лично я бы начал с обособленных участков кода и классов, которые выглядят вполне самостоятельными. Например, я решил, что для моего проекта мне понадобится самописная хеш-таблица. Это же отличный кандидат на покрытие Unit-тестами! Интерфейс понятен и меняться не будет, так что написать тесты сам бог велел. И вот я воодушевлённо трачу своё рабочее время, накидывая десятки тестов. Может быть, я даже выловлю несколько багов в своём коде (боже, как я хорош, как мощны мои тесты) и и спустя два месяца я вдруг понимаю, что хеш-таблица мне вовсе не нужна, лучше бы её заменить базой данных. И все мои рабочие часы на Unit-тесты (и выловленные баги) летят в помойку.

Обидно? Ну что ж, с кем не бывает, ничего страшного. Это ведь не повод отказываться от Unit-тестов, верно? Сделаем заметку и рассмотрим вторую опасную ситуацию.

Отловив все очевидные участки кода, которые можно покрыть Unit-тестами, вы вдруг понимаете, что вы покрыли всего 10% кода (ну нет у вас сейчас четких обособленных модулей с внятными интерфейсами на такой стадии проекта). Тогда вы начинаете беспощадно рефакторить свой код выделяете абстрактные классы, выстраиваете зону ответственности между модулями, инкапсулируете, инкапсулируете, инкапсулируете занимаетесь, в общем-то, полезными делами, честно говоря. Ну и каждый свой успех отмечаете очередной порцией Unit-тестов, ведь ради них, родимых, всё и затевается!

Спустя пару недель работы вы получаете 60% покрытого тестами кода. У вас появилась сложная иерархия классов, mock-объекты, а общее количество Unit-тестов перевалило за 100500. Всё хорошо, так ведь?

Всё хорошо ровно до тех пор, пока вы не увидите, что вашу архитектуру можно было бы улучшить (а с развитием проектов, особенно новых, такие наблюдения случаются регулярно). И вместо того, чтобы смело ринуться в дебри рефакторинга, вы начинаете грустно думать о 100500 Unit-тестах и о том, как теперь вам придётся их переделывать. Вы становитесь заложником своих собственных Unit-тестов, которые начинают сковывать вашу гибкость в принятии архитектурных решений. И выбор у вас получается так себе. Либо решиться на рефакторинг и спустить в унитаз всё время, потраченное на Unit-тесты, либо (ещё хуже) оставить всё как есть, и затем бороться с не самой удачной (как вы теперь понимаете) архитектурой.

Звучит так, как будто я просто персонально терпеть не могу Unit-тесты и пытаюсь отговорить вас от их использования, так?

Вовсе нет. Просто для любого нового проекта это абсолютно нормальная ситуация в какой-то момент понять, что изначальная архитектура или затея вышла не слишком удачной и что нужно всё (или практически всё) переделывать. Вам всё равно с высокой долей вероятности придётся через это пройти. И наличие Unit-тестов вас не только не спасёт оно даже сыграет с вами злую шутку: вместо того, чтобы взвешенно и объективно принять решение о реструктуризации кода, вы будете только грустно вспоминать о потраченных часах и даже днях на составление сотен, тысяч юнит-тестов. Мне было бы жалко времени, потраченного на Unit-тесты, которые теперь надо выкинуть в помойку и начинать писать заново.

Лучше спешите с системными тестами!

Так что же я предлагаю? А предлагаю я взглянуть на старый рисунок по-новому:

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

Как я уже упоминал выше, системные тесты это тесты программы в целом. При этом программа представляется именно в том виде, в котором её увидит пользователь. Фактически, системные тесты заставляют нас взглянуть на программу как на законченный продукт (хоть он таким сейчас и не является). Если другими словами, то вместо подхода от "от частного к общему" мы начинаем писать тесты "от общего к частному". А это позволяет нам убить сразу двух зайцев:

1. Прорабатывая системные тесты, мы формализуем и фиксируем требования к программе в виде скриптов, которые или проходят или нет. Соответственно, будет гораздо меньше споров о том, когда фичу можно считать законченной.
2. Системные тесты позволяют очень четко визуализировать и разложить по полочкам то, как наша программа будет выглядеть для конечного пользователя. Это уже ценно само по себе, но также позволяет обнаружить на ранних этапах несостыковки в требованиях (а они всегда есть). Также становится понятным, какие моменты требуют дальнейшей проработки.

Звучит неплохо, не правда ли? Причём, системные тесты обладают ещё рядом очень приятных бонусов:

1. В условиях зафиксированных требований к программе системные тесты не могут сильно меняться. Это возможно благодаря самой природе системных тестов: они рассматривают программу как "черный ящик" без какой-либо привязки к архитектуре и особенностям реализации. А это значит, что вы можете свободно менять архитектуру своей программы по первому требованию, и никакие тесты менять не придется! Ну, разве что, немного подкорректировать если у вас добавилась новая зависимость или что-то в таком духе.
2. Системные тесты могут писать аналитики или даже тестировщики не отнимая, таким образом, ценное время программистов. Также это позволяет аналитикам дать программистам более четкое понимание, что именно они хотят увидеть в программе. Программистам лишь останется добиться того, чтобы тесты проходили, не ломая голову над вопросом "чего же от меня хотят".
3. Системные тесты это очень комплексный вид тестов. Если ваша программа проходит сложный комплексный тест то вы уже с довольно высокой долей вероятности можете быть уверены, что "в целом, наверное, все компоненты нормально работают". В Unit-тестах наоборот уверенность в одном классе не дает абсолютно никакой уверенности в работоспособности программы в целом.

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

Впрочем, сейчас на этом фронте не всё так уж и плохо существует очень много коммерческих решений, которые позволяют в том или ином виде решить эту проблему: Testcomplete, Squish, Ranorex, Eggplant это лишь самые известные примеры таких систем. У всех у них есть свои достоинства и недостатки, но в целом со своей задачей по автоматизации системных тестов они справляются (хоть и стоят очень немалых денег).

А вот среди бесплатных решений выбора особо нет. По крайней мере не было.

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

А что же другие тесты?

Заметьте, что я сосредоточился на том, что стоит начинать с системных тестов, потому что это даёт определенные неплохие бонусы. Но это отнюдь не означает, что стоит пренебрегать другими видами тестов.

В самом деле, системные тесты дают неплохое представление о том, что программа в целом работает, но при этом они не ограничивают вашу свободу при работе скальпелем в вашем проекте. Но это не отменяет того факта, что системные тесты всё равно остаются довольно тяжеловесными (даже с учётом автоматизации) и их действительно невозможно клепать с той же легкостью и скоростью, как API-тесты или, тем более, Unit-тесты.

В развитием проекта вы обнаружите, что вас уже не устраивает только проверка "в целом всё работает". Со временем архитектура вашего нового приложения неизбежно "устаканится", крупных изменений будет всё меньше и меньше. В какой-то момент вы поймёте, что вы хотите навесить побольше проверок на какой-нибудь компонент (потому что он уже точно никуда из проекта не денется, и его интерфейс точно проработан), или даже на конкретный класс А для особо важных участков кода и вовсе желательно проработать все возможные ветвления. Или же вам очень интересно, как поведёт себя программа при непосредственном обращении к API. Чувствуете, да? Вот и другие тесты снова в деле!

На основе всего вышеизложенного, я бы хотел предложить следующий вариант развития тестов в проекте:

1. В самом начале, когда проект активного развивается с нулевого состояния, необходимо писать только системные тесты. Тестов нужно написать столько, чтобы у вас была четкая уверенность, что "в целом моя программа работает нормально". Это будет отличный базис для дальнейшей работы.
2. По мере развития проекта и "устаканивания" его архитектуры и основных компонентов можно добавлять интеграционные тесты. Если у проекта появилось чётко выраженное и стабильное API нужно начинать писать API-тесты.
3. Наконец, для особо важных изолированных участков кода, от правильной работы которых зависит очень многое, можно написать Unit-тесты.
4. Помнить, что из любого правила есть исключения. При возникновении достаточно веских объективных причин повышайте приоритет интеграционных и Unit-тестов. Не нужно откладывать разработку тестов более низкого уровня, если вы в них действительно нуждаетесь здесь и сейчас.

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

Итоги

Вроде бы про разработку "от общего к частному" уже давным давно всё известно вдоль и поперёк, но при этом тесты всё равно упорно составляются "от частного к общему". Возможно, это дело привычки, а возможно в том, что так просто удобнее ведь написать двадцать Unit-тестов всегда проще, чем пару системных тестов.

Но по мере развития инструментов для автоматизации системных тестов перспектива сходу автоматизировать end-to-end тесты уже не кажется такой уж пугающей. Возможно, вам понравится разрабатывать тесты "сверху вниз" ведь так их можно разрабатывать ровно по мере их надобности.

Программа

Топ-10 вредных советов и к чему они могут привести (Ирина Ушакова, EPAM, Нижний Новгород)

Автоматизация тестирования мобильного приложения Яндекс.Деньги (Александр Наташкин, Яндекс.Деньги, Санкт-Петербург)

Отлавливаем баги в коде и рабочем процессе (Елена Гурова, Usetech, Ростов-на-Дону)

• А давайте релиз в пятницу, во второй половине дня?
• Как это попало в продакшн?!
• Вы же уже исправляли это, почему опять сломано?

Качество релизов ответственность команды (Людмила Малеева, Miro, Пермь)

Круглый стол с программным комитетом QA Meeting Point

• Правда или миф: хороший QA-инженер не будет оставаться в профессии, а станет разработчиком
• Не надо так: деплоймент на продакшн по пятницам и тестирование на прод
• Стоит ли ломать продакшн для проверки высокой доступности и безопасности

Регистрация

О чем будем говорить

Как мы начали использовать Cypress в тестировании и не прогадали

Оркестр на изоляции: автоматизируем тесты Camunda

Что делать, если у вас слишком много автотестов

Где логика?! История тестирования одного микросервиса

Автоматизация тестирования мобильного приложения Яндекс.Деньги

Отлавливаем баги в коде и рабочем процессе

• А давайте релиз в пятницу, во второй половине дня?
• Как это попало в продакшн?!
• Вы же уже исправляли это, почему опять сломано?

Качество релизов ответственность команды

Правда или миф: хороший QA-инженер не будет оставаться в профессии, а станет разработчиком

QA Meeting Point 2020: как это было

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

Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.

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

Этот гайд предполагает, что у вас уже установлен python, настроен пустой репозиторий, куда вы будете отправлять свой код. При чтении статьи не обязательно знать pytest, но очень желательно знать что из себя представляет фикстура, как ей пользоваться, а так же параметризация тестов. Для тестирования будет использован Dog API. Если вас интересует локальный запуск тестов через gitlab, то вам необходимо установить docker.

Если у вас не установлено вышеперечисленное ПО, то ниже вы можете найти полезные ссылки:

• Установка Python
• Установка Allure Если вы хотите генерировать отчеты локально. В данной статье такой метод не рассматривается.
• Скачать PyCharm Community
• Настройка ssh в git для отправки кода в gitlab
• Pytest краткое руководство

Содержание

• Подготовка к написанию тестов
• Написание фикстуры и небольшого клиента для API тестов
• Пишем тесты
• Добавляем allure в тесты
• Делаем инфраструктуру для тестов
• Настройка репозитория
• Установка и настройка Gitlab Runner
• Настройка пайплайна в .gitlab-ci.yml
• Запуск тестов и просмотр отчета
• Настройка пайплайна для UI тестов
• Полезные ссылки

Подготовка к написанию тестов

Я назвал свой репозиторий для этой статьи allure_pages и скопировал его на свой компьютер.

Нужно создать такую структуру в директории с репозиторием:

• conftest.py будет использован для написания фикстур
• requirements.txt для установки необходимых модулей в контейнере с python
• test_dog_api.py внутри отдельной директории tests для написания самих тестов

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

python -m venv venv

Открываем папку с репозиторием как проект в PyCharm

Удобнее всего, на мой взгляд устанавливать нужные нам пакеты через встроенный в PyCharm терминал. Для этого нужно добавить интерпретатор, и открыть терминал.

1. Жмем на Add Interpreter и если вы ранее создали в директории с проектом виртуальное окружение, то PyCharm сразу найдет нужный интерпретатор, который будет использован в проекте
2. Открываем терминал по этой кнопке

Устанавливаем нужные пакеты для наших тестов в виртуальном окружении:

Для этого введите в терминал следующие команды.

• pip install requests для запросов, которые мы будем делать к сервису Dog Api
• pip install pytest для тестов, само собой
• pip install pytest-xdist для параллелизации тестов
• pip install allure-pytest для генерации отчетов в allure

Очень важно после этого написать в терминале
pip freeze > requirements.txt.

Файл requirements.txt нам понадобится для запуска тестов внутри докер контейнера.

Написание фикстуры и небольшого клиента для API тестов

Для того, чтобы упростить наши тесты создадим небольшой клиент для GET и POST запросов. Далее будет подробное описание этого клиента. Если вам это не нужно или кажется сложным, то пропустите эту часть статьи и переходите к следующей. На примере её использования станет ясно как пользоваться клиентом.

Сама фикстура

@pytest.fixturedef dog_api():    return ApiClient(base_address="http://personeltest.ru/aways/dog.ceo/api/")

Ниже конструктор класса для клиента. При инициализации объекта класс принимает в себя аргумент base_address, на его место нужно записать в фикстуре общий адрес для всех запросов в нашем случае будет использован https://dog.ceo/api/. Обратите внимание, что фикстура возвращает объект с базовым адресом для дальнейших GET и POST запросов.

class ApiClient:    def __init__(self, base_address):        self.base_address = base_address

Добавим в класс метод GET для отправки запросов.

    def get(self, path="/", params=None, headers=None):        url = f"{self.base_address}{path}"        return requests.get(url=url, params=params, headers=headers)

Здесь можно заметить, что наш клиент является оберткой над библиотекой requests. В классе ApiClient аргументы path, params, headers метода get выступают в роли аргументов, которые передаются в requests.get(url=url, params=params, headers=headers). Именно эта строчка и отвечает за выполнение запросов. Из адреса, использованного при инициализации объекта и пути, который мы передадим в дальнейшем в ходе теста, будет складываться полный адрес, который и будет использоваться в requests.get.

Добавим в класс метод POST. Его логика идентична, просто добавляется несколько аргументов, которые при желании можно заполнить данными.

    def post(self, path="/", params=None, data=None, json=None, headers=None):        url = f"{self.base_address}{path}"        return requests.post(url=url, params=params, data=data, json=json, headers=headers)

В итоге у нас получается такой файл conftest.py:

import pytestimport requestsclass ApiClient:    def __init__(self, base_address):        self.base_address = base_address    def post(self, path="/", params=None, data=None, json=None, headers=None):        url = f"{self.base_address}{path}"        return requests.post(url=url, params=params, data=data, json=json, headers=headers)    def get(self, path="/", params=None, headers=None):        url = f"{self.base_address}{path}"        return requests.get(url=url, params=params, headers=headers)@pytest.fixturedef dog_api():    return ApiClient(base_address="http://personeltest.ru/aways/dog.ceo/api/")

Пишем тесты

В самом сервисе Dog API есть много разных запросов. Если у вас есть опыт в написании тестов, то можете самостоятельно написать несколько тестов. Так как акцент в этой статье заключается в постройке инфраструктуры для тестов, я не буду вдаваться в подробности тестов. Ранее я это сделал, чтобы мой код был более менее понятен. Несколько параметризованных тестов специально сломаны, чтобы показать как они будут показаны в отчете. Так выглядит мой файл с тестами test_dog_api.py

import pytestdef test_get_random_dog(dog_api):    response = dog_api.get("breeds/image/random")    with allure.step("Запрос отправлен, посмотрим код ответа"):        assert response.status_code == 200, f"Неверный код ответа, получен {response.status_code}"    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()        assert response["status"] == "success"    with allure.step(f"Посмотрим что получили {response}"):        with allure.step(f"Вложим шаги друг в друга по приколу"):            with allure.step(f"Наверняка получится что-то интересное"):                pass@pytest.mark.parametrize("breed", [    "afghan",    "basset",    "blood",    "english",    "ibizan",    "plott",    "walker"])def test_get_random_breed_image(dog_api, breed):    response = dog_api.get(f"breed/hound/{breed}/images/random")    response = response.json()    assert breed in response["message"], f"Нет ссылки на изображение с указанной породой, ответ {response}"@pytest.mark.parametrize("file", ['.md', '.MD', '.exe', '.txt'])def test_get_breed_images(dog_api, file):    response = dog_api.get("breed/hound/images")    response = response.json()    result = '\n'.join(response["message"])    assert file not in result, f"В сообщении есть файл с расширением {file}"@pytest.mark.parametrize("breed", [    "african",    "boxer",    "entlebucher",    "elkhound",    "shiba",    "whippet",    "spaniel",    "dvornyaga"])def test_get_random_breed_images(dog_api, breed):    response = dog_api.get(f"breed/{breed}/images/")    response = response.json()    assert response["status"] == "success", f"Не удалось получить список изображений породы {breed}"@pytest.mark.parametrize("number_of_images", [i for i in range(1, 10)])def test_get_few_sub_breed_random_images(dog_api, number_of_images):    response = dog_api.get(f"breed/hound/afghan/images/random/{number_of_images}")    response = response.json()    final_len = len(response["message"])    assert final_len == number_of_images, f"Количество фото не {number_of_images}, а {final_len}"

Добавляем allure в тесты

Есть много разных подходов к написанию тестов с помощью allure. Так как сейчас рассматривается больше инфраструктура, то добавим совсем простые шаги. Для понимания написанного мною кода, я все же прокомментирую несколько моментов.

with allure.step('step 1'): с помощью этого контекстного менеджера тело теста делится на шаги, понятные в отчете.
@allure.feature('Dog Api') @allure.story('Send few requests') декораторы, с помощью которых сами тесты или тестовые наборы будут структурированы в отчете

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

Добавим в наш API клиент несколько allure шагов.

class ApiClient:    def __init__(self, base_address):        self.base_address = base_address    def post(self, path="/", params=None, data=None, json=None, headers=None):        url = f"{self.base_address}{path}"        with allure.step(f'POST request to: {url}'):            return requests.post(url=url, params=params, data=data, json=json, headers=headers)    def get(self, path="/", params=None, headers=None):        url = f"{self.base_address}{path}"        with allure.step(f'GET request to: {url}'):            return requests.get(url=url, params=params, headers=headers)

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

@allure.feature('Random dog')@allure.story('Получение фото случайной собаки и вложенные друг в друга шаги')def test_get_random_dog(dog_api):    response = dog_api.get("breeds/image/random")    with allure.step("Запрос отправлен, посмотрим код ответа"):        assert response.status_code == 200, f"Неверный код ответа, получен {response.status_code}"    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()        assert response["status"] == "success"    with allure.step(f"Посмотрим что получили {response}"):        with allure.step(f"Вложим шаги друг в друга по приколу"):            with allure.step(f"Наверняка получится что-то интересное"):                pass

Сходным образом заполним шагами и декораторами остальные тесты. Финальный файл test_dog_api.py

import pytestimport allure@allure.feature('Random dog')@allure.story('Получение фото случайной собаки и вложенные друг в друга шаги')def test_get_random_dog(dog_api):    response = dog_api.get("breeds/image/random")    with allure.step("Запрос отправлен, посмотрим код ответа"):        assert response.status_code == 200, f"Неверный код ответа, получен {response.status_code}"    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()        assert response["status"] == "success"    with allure.step(f"Посмотрим что получили {response}"):        with allure.step(f"Вложим шаги друг в друга по приколу"):            with allure.step(f"Наверняка получится что-то интересное"):                pass@allure.feature('Random dog')@allure.story('Фото случайной собаки из определенной породы')@pytest.mark.parametrize("breed", [    "afghan",    "basset",    "blood",    "english",    "ibizan",    "plott",    "walker"])def test_get_random_breed_image(dog_api, breed):    response = dog_api.get(f"breed/hound/{breed}/images/random")    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()    assert breed in response["message"], f"Нет ссылки на фото с указанной породой, ответ {response}"@allure.feature('List of dog images')@allure.story('Список всех фото собак списком содержит только изображения')@pytest.mark.parametrize("file", ['.md', '.MD', '.exe', '.txt'])def test_get_breed_images(dog_api, file):    response = dog_api.get("breed/hound/images")    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()    with allure.step("Соединим все ссылки в ответе из списка в строку"):        result = '\n'.join(response["message"])    assert file not in result, f"В сообщении есть файл с расширением {file}"@allure.feature('List of dog images')@allure.story('Список фото определенных пород')@pytest.mark.parametrize("breed", [    "african",    "boxer",    "entlebucher",    "elkhound",    "shiba",    "whippet",    "spaniel",    "dvornyaga"])def test_get_random_breed_images(dog_api, breed):    response = dog_api.get(f"breed/{breed}/images/")    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()    assert response["status"] == "success", f"Не удалось получить список изображений породы {breed}"@allure.feature('List of dog images')@allure.story('Список определенного количества случайных фото')@pytest.mark.parametrize("number_of_images", [i for i in range(1, 10)])def test_get_few_sub_breed_random_images(dog_api, number_of_images):    response = dog_api.get(f"breed/hound/afghan/images/random/{number_of_images}")    with allure.step("Запрос отправлен. Десериализируем ответ из json в словарь."):        response = response.json()    with allure.step("Посмотрим длину списка со ссылками на фото"):        final_len = len(response["message"])    assert final_len == number_of_images, f"Количество фото не {number_of_images}, а {final_len}"

Делаем инфраструктуру для тестов

Здесь есть несколько моментов, о которых стоит написать:

• .gitlab-ci.yml файл, где на языке разметки yaml описаны инструкции что нужно делать gitlab runner
• gitlab-runner это проект, написанный на языке Go. Он будет выполнять инструкции. Есть несколько вариантов его использования. Мы будем писать инструкцию для gitlab runner, где он в свою очередь будет использовать docker для запуска тестов и всего остального. Далее по тексту он будет обозначаться просто "раннер". Что это за сущность и с чем её едят можно найти здесь.

Если у вас в компании уже настроена инфраструктура и вы можете попросить своего devops выделить вам раннер где-то в облаке, то сделайте это. Раннер можно использовать и локально на своем компьютере. В этом случае вам нужен установленный docker desktop на windows. В этом гайде мы будем использовать локальный раннер, но для облачного запуска вам нужно будет просто указать в .gitlab-ci нужный раннер.

Если у вас нет docker desktop, то здесь инструкция как его заиметь.

Настройка репозитория

Нужно зайти в настройки репозитория Settings -> General -> Visibility, project features, permissions, активировать Pipelines и сохранить изменения.

После этого в разделе настроек появится раздел CI / CD. Переходим Settings -> CI / CD -> Runners

Здесь переходим по ссылке в пункте 1 и согласно инструкции ставим себе на компьютер Gitlab Runner. Далее в статье адаптация инструкции на русском.

Установка и настройка Gitlab Runner

Ниже инструкция, которую вы можете найти здесь. Можете пройтись по ней самостоятельно. Далее в тексте будет сделано все по инструкции.

1. Создайте папку где-нибудь в системе, например: C:\GitLab-Runner.
2. Скачайте бинарник для x86 или amd64 и положите его в созданную папку. Переименуйте скачанный файл в gitlab-runner.exe. Вы можете скачать бинарник для любой доступной версии здесь
3. Запустите командную строку с правами администратора. (Сам я буду использовать обычный powershell с правами администратора)
4. Зарегестрируйте раннер
5. Установите раннер как сервис и запустите его. Вы можете запустить службу, используя встроенную системную учетную запись (рекомендуется) или учетную запись пользователя.

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

Я создал папку C:\gitlab_runners и сохранил туда скачанный для моей системы раннер, предварительно переименовав в gitlab-runner.exe

Как только вы справились с первыми тремя пунктами, то нужно сделать следующее:

1. Ввести команду:
   ./gitlab-runner.exe register
2. Ввести url, указанный на странице настроек раннеров в репозитори в пункте 2. Например, у меня так:
   https://gitlab.somesubdomain.com/
3. Ввести токен указанный на странице настроек раннеров в репозитори в пункте 3. Например, у меня так:
   tJTUaJ7JxfL4yafEyF3k
4. Вводим описание раннера. Его потом можно будет изменить через UI в настроках раннера в репозитории. Например так:
   Runner on windows for autotests
5. Добавляем теги для раннера, для того, чтобы описывать нужный раннер в .gitlab-ci.yml, используя определенные теги. Это в основном нужно, когда раннеров больше одного.
   docker, windows
6. Выбираем тип раннера, который нам нужен. Здесь выберем docker
   docker
7. Вводим дефолтный image, который будет использоваться раннером. Его можно будет изменить в конфиге раннера или указать конкретый в .gitlab-ci.yml
python:3.8-alpine

Скрншот с выполнеными шагами

Наш раннер зарегистрирован, теперь его нужно запустить.

Проверить статус раннера можно так:
.\gitlab-runner.exe status

Запустите раннер с помощью:
.\gitlab-runner.exe run

Теперь, если вы зайдете в настроки раннеров в репозитории Settings -> CI / CD -> Runners, то увидите что-то такое:

Это означает, что у репозитория есть линк с раннером и он видит его статус. Осталось добавить чекбокс в раннере. Для этого нужно нажать на карандаш рядом с именем раннера в гитлабе.

Все хорошо, теперь можно перейти к пайплайну.

Настройка пайплайна в .gitlab-ci.yml

Инструкции для раннера описываются в .gitlab-ci.yml. Полная документация описана здесь.

Первым делом нам нужно описать stages. Шаги пайплайна. Их будет 4. Каждый stage отдельный job, который будет выполнять раннер.

stages:  - testing # Запуск тестов  - history_copy # Копирование результата тестов из предыдущего запуска тестов  - reports # Генерация отчета  - deploy # Публикация отчета на gitlab pages

Шаг первый. Testing

docker_job: # Название job  stage: testing # Первый stage, который нужно выполнить  tags:    - docker # С помощью этого тега gitlab поймет, какой раннер нужно запустить. Он запустит докер контейнер, из образа, который мы указывали в 6 шаге регистрации раннера.  before_script:    - pip install -r requirements.txt # Устанавливаем пакеты в поднятом контейнере перед запуском самих тестов  script:    - pytest -n=4 --alluredir=./allure-results tests/test_dog_api.py # Запускаем тесты параллельно(-n=4 обеспечивает нам это), указав папку с результатами тестов через --alluredir=  allow_failure: true # Это позволит нам продолжить выполнение пайплайна в случае, если тесты упали.  artifacts: # Сущность, с помощью которой, мы сохраним результат тестирования.    when: always # Сохранять всегда    paths:      - ./allure-results # Здесь будет сохранен отчет    expire_in: 1 day # Да, он будет удален через день. Нет смысла хранить его в течение длительного срока.

Шаг второй. history_copy

history_job: # Название job  stage: history_copy # Это второй stage, который нужно выполнить  tags:    - docker # Пользуемся тем же самым раннером  image: storytel/alpine-bash-curl # Но теперь укажем раннеру использовать другой образ, для того чтобы скачать результаты теста из предыдущего пайплайна. Нам же нужна история тестов, верно?  script:    - 'curl --location --output artifacts.zip "https://gitlab.smarthead.ru/api/v4/projects/(АЙДИ ВАШЕГО РЕПОЗИТОРИЯ)/jobs/artifacts/master/download?job=pages&job_token=$CI_JOB_TOKEN"'  # С помощью api гитлаба скачиваем файлы из job, который будет указан ниже. Обратите внимание на текст на русском в ссылке. Очень важно указать вместо текста и скобок номер вашего репозиториия    - unzip artifacts.zip # Распаковываем файлы    - chmod -R 777 public # Даем права любые манипуляции с содержимым    - cp -r ./public/history ./allure-results # Копируем историю в папку с результатами теста  allow_failure: true # Так как при первом запуске пайплайна истории нет, это позволит нам избежать падения пайплайна. В дальнейшем эту строчку можно спокойно удалить.  artifacts:     paths:      - ./allure-results # Сохраняем данные    expire_in: 1 day  rules:    - when: always # Сохранять всегда

Шаг третий. reports

allure_job: # Название job  stage: reports # Третий stage, который будет выполнен  tags:    - docker # Пользуемся тем же самым раннером  image: frankescobar/allure-docker-service # Указываем раннеру использовать образ с allure. В нем мы будем генерировать отчет.  script:     - allure generate -c ./allure-results -o ./allure-report # Генерируем отчет из ./allure-results внутрь папки ./allure-report  artifacts:    paths:      - ./allure-results # Примонтируем две этих директории для получения результатов тестирования и генерации отчетов соответственно      - ./allure-report    expire_in: 1 day  rules:    - when: always

Шаг четвертый. deploy

pages: # Названием этой job говорим гитлабу, чтобы захостил результат у себя в pages  stage: deploy # Четвертый stage, который будет выполнен  script:    - mkdir public # Создаем папку public. По умолчанию гитлаб хостит в gitlab pages только из папки public    - mv ./allure-report/* public # Перемещаем в папку public сгенерированный отчет.  artifacts:    paths:      - public  rules:    - when: always

Финальный .gitlab-ci.yml

stages:  - testing # Запуск тестов  - history_copy # Копирование результата тестов из предыдущего запуска тестов  - reports # Генерация отчета  - deploy # Публикация отчета на gitlab pagesdocker_job: # Название job  stage: testing # Первый stage, который нужно выполнить  tags:    - docker # С помощью этого тега gitlab поймет, какой раннер нужно запустить. Он запустит докер контейнер, из образа, который мы указывали в 6 шаге регистрации раннера.  before_script:    - pip install -r requirements.txt # Устанавливаем пакеты в поднятом контейнере перед запуском самих тестов  script:    - pytest -n=4 --alluredir=./allure-results tests/test_dog_api.py # Запускаем тесты параллельно(-n=4 обеспечивает нам это), указав папку с результатами тестов через --alluredir=  allow_failure: true # Это позволит нам продолжить выполнение пайплайна в случае, если тесты упали.  artifacts: # Сущность, с помощью которой, мы сохраним результат тестирования.    when: always # Сохранять всегда    paths:      - ./allure-results # Здесь будет сохранен отчет    expire_in: 1 day # Да, он будет удален через день. Нет смысла хранить его в течение длительного срока.history_job: # Название job  stage: history_copy # Это второй stage, который нужно выполнить  tags:    - docker # Пользуемся тем же самым раннером  image: storytel/alpine-bash-curl # Но теперь укажем раннеру использовать другой образ, для того чтобы скачать результаты теста из предыдущего пайплайна. Нам же нужна история тестов, верно?  script:    - 'curl --location --output artifacts.zip "https://gitlab.smarthead.ru/api/v4/projects/(АЙДИ ВАШЕГО РЕПОЗИТОРИЯ)/jobs/artifacts/master/download?job=pages&job_token=$CI_JOB_TOKEN"'  # С помощью api гитлаба скачиваем файлы из job, который будет указан ниже. Обратите внимание на текст на русском в ссылке. Очень важно указать вместо текста и скобок номер вашего репозиториия    - unzip artifacts.zip # Распаковываем файлы    - chmod -R 777 public # Даем права любые манипуляции с содержимым    - cp -r ./public/history ./allure-results # Копируем историю в папку с результатами теста  allow_failure: true # Так как при первом запуске пайплайна истории нет, это позволит нам избежать падения пайплайна. В дальнейшем эту строчку можно спокойно удалить.  artifacts:     paths:      - ./allure-results # Сохраняем данные    expire_in: 1 day  rules:    - when: always # Сохранять всегдаallure_job: # Название job  stage: reports # Третий stage, который будет выполнен  tags:    - docker # Пользуемся тем же самым раннером  image: frankescobar/allure-docker-service # Указываем раннеру использовать образ с allure. В нем мы будем генерировать отчет.  script:     - allure generate -c ./allure-results -o ./allure-report # Генерируем отчет из ./allure-results внутрь папки ./allure-report  artifacts:    paths:      - ./allure-results # Примонтируем две этих директории для получения результатов тестирования и генерации отчетов соответственно      - ./allure-report    expire_in: 1 day  rules:    - when: alwayspages: # Названием этой job говорим гитлабу, чтобы захостил результат у себя в pages  stage: deploy # Четвертый stage, который будет выполнен  script:    - mkdir public # Создаем папку public. По умолчанию гитлаб хостит в gitlab pages только из папки public    - mv ./allure-report/* public # Перемещаем в папку public сгенерированный отчет.  artifacts:    paths:      - public  rules:    - when: always

Запуск тестов и просмотр отчета

Осталось отправить в репозиторий все необходимые файлы, а именно:

1. conftest.py
2. Директорию tests
3. requirements.txt (Убедитесь, что там есть все нужные зависимости)
4. .gitlab-ci.yml

Отправляем и смотрим что получилось.

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

Здесь вы сможете увидеть статус пайплайна, а также перейти к Ci линтеру, где можете проверить конкретно свой .gitlab-ci.yml.

Когда пайплайн пройдет, увидеть ссылку и сам отчет можно через Settings -> Pages. При первом использовании pages в репозитории для просмотра страницы может понадобиться до 30 минут. Проходим по ссылке и смотрим отчет.

Получаем результат. Советую побродить по отчету и посмотреть результаты.

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

Как видите второй шаг в этот раз выполнился без ошибок. Это потому, на stage history_job проблем с копированием истории предыдущих пайплайнов не возникло. Теперь посмотрим результат тестов.

Видна динамика, количество упавших тестов и все остальное. Для просмотра подробностей по тестам рекомендую посмотреть отчет самостоятельно.

Настройка пайплайна для UI тестов

Реализовать их можно с помощью специальной сущности гитлаба [services](http://personeltest.ru/aways/docs.gitlab.com/ee/ci/services/). Это ключевое слово для использования докер образов, которые будут запущены до хода шагов в script. Для UI тестов нужно добавить в job пайплайна следующее:

  services:    - selenium/standalone-chrome:latest

Так как нам нужно обращаться к контейнеру, который поднимет гитлаб по определенному url, то он каким-то образом назначает этому сервису url, по которому можно слать запросы. Логика здесь такая:

• Все после : отбрасывается
• Слеш / заменяется двойным подчеркиванием __ и создается главный алиас
• Слеш / заменяется одиночным дефисом - и создается дополнительный алиас (Необходим Gitlab Runner v1.1.0 и выше)

И теперь нужно изменить в фикстуре executor (по умолчанию используется chromedriver на вашей машине, но сейчас мы все это запускаем в контейнерах) для запуска ui тестов:

browser = webdriver.Remote(command_executor="http://personeltest.ru/away/selenium__standalone-chrome:4444/wd/hub")

Обратите внимание, что было в .gitlab-ci.yml:
selenium/standalone-chrome:latest
И по какому адресу нужно обращаться фикстуре для запуска тестов:
selenium__standalone-chrome

Для запуска моих тестов у меня получился такой job. Если добавить к нему три следующих job из примера с api тестами, то можно прогнать все тесты и получить отчет.

chrome_job:  stage: testing  services:    - selenium/standalone-chrome  image: python:3.8  tags:    - docker  before_script:    - pip install -r requirements.txt  script:    - pytest --alluredir=./allure-results tests/  allow_failure: true  artifacts:    when: always    paths:      - ./allure-results    expire_in: 1 day

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

Помимо ссылок в статье, хочется поделиться еще несколькими, которые немного разъяснять вам что такое allure и как писать gitlab ci.

Статья об allure на хабре
Введение в gitlab ci

Эта статья посвящена автоматизации системного (end-to-end) тестирования с использованием виртуальных машин. В статье рассматриваются такие вопросы, как автоматизация развертывания и настройки виртуальных стендов, а также автоматизация запуска процессов внутри виртуальных машин с последующим контролем полученных результатов. В конце статьи мы получим пусть неидеальный (к этому мы ещё вернемся), но простой и понятный скрипт, с помощью которого вы сможете запускать системные тесты одной кнопкой, даже не имея у себя на компьютере ни одной виртуальной машины.

Статья предполагает наличие следующих навыков у читателя:

• Уверенное пользование ОС семейства Linux;
• Базовое понимание принципов виртуализации;
• Знакомство с гипервизором QEMU и графическим клиентом virt-manager

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

Что такое системное тестирование

Системное тестирование (или, как его ещё иногда называют, end-to-end тестирование) это тестирование программы (или даже целой системы) с учётом окружения, в которой программе придётся работать. Помимо системного тестирования также существует unit-тестирование (тестирование конкретных функций и модулей), интеграционное тестирование (тестирование больших самостоятельных компонент программы или программы целиком) и ещё много других видов тестирования. Но почему же нас может заинтересовать именно системное?

Наверное, у всех бывали ситуации, когда у разработчика всё работает, а у заказчика вечно что-то ломается. Так вот, системное тестирование хорошо тем, что программа проверяется именно в том виде, в котором её увидит конечный потребитель. Системные тесты позволяют воспроизвести некоторое окружение и проверить, как программа с этим окружение справляется. Вот некоторые примеры настраиваемого окружения:

• Вид и версия ОС;
• Разные настройки ОС (например, в области разграничения прав доступа);
• Наличие или отсутствие определенных программ в ОС (в т.ч. драйверов);
• Наличие сети и других компьютеров в ней;
• Количество оперативной памяти или определённая архитектура процессора.

Довольно часто разработчики и тестировщики просто не знают, как подступиться к задаче автоматизации системных тестов, либо им кажется, что затраты на автоматизацию не окупят себя. Этой статьёй я хотел бы продемонстрировать, что автоматизация системных тестов не настолько сложна, как это может показаться, и я надеюсь, что она послужит для кого-то хорошей отправной точкой.

Почему именно виртуалки?

Может возникнуть вопрос, а зачем использовать именно виртуалки? Ведь для воспроизведения окружения для программы можно использовать и контейнеры (например, если Вас интересует поведение программы в связке с другими программами). И действительно, для контейнеров существует несколько решений по автоматизации тестов. Однако, существуют классы сценариев, которые нельзя протестировать с помощью контейнеров:

1. Нельзя протестировать приложения не под Linux, а также гетерогенные стенды из нескольких машин;
2. Нельзя протестировать GUI (или даже псевдо-GUI);
3. Нельзя протестировать драйвера и работу с оборудованием.

Автоматизация пунктов 1 и 2 потребует от нас существенной подготовки, поэтому оставим их для одной из следующих статей. А вот для пункта 3 вполне хватит той информации, которую Вы узнаете из этой статьи. В этой статье (во второй её части) мы как раз продемонстрируем автоматизацию тестирования приложения, которое взаимодействует с оборудованием напрямую, в обход операционной системы.

Какой выбрать гипервизор?

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

Какие действия мы хотим автоматизировать?

Для того, чтобы автоматизировать системные тесты, нам нужно решить как минимум следующие вопросы:

1. Как автоматически создать виртуалку;
2. Как "раскатать" и настроить ОС;
3. Как научиться управлять виртуалкой после её установки. В частности, нас интересует, как запускать процессы внутри виртуалки и копировать на неё файлы.

Что ж, погнали!

Создаем виртуалку

Конечно, я думаю все пробовали создавать виртуальные машины вручную. Для этого в графическом интерфейсе рисуются всякие диалоговые окна, где надо выбрать конфигурацию, диски, сетевые адаптеры и прочее прочее. Так вот, для гипервизора QEMU всё это можно сделать и в консольном режиме с помощью утилиты virt-install. Давайте посмотрим как будет выглядеть простейшее создание виртуальной машины с помощью этой утилиты:

virt-install \    --name my_super_vm \    --ram 1024 \    --disk my_super_vm.qcow2,size=8 \    --cdrom /path/to/ubuntu_server.iso

Вот такой простой командой мы можем создать виртуальную машину с именем my_super_vm, 1024 Мегабайтами оперативной памяти, новым диском my_super_vm.qcow2 размером 8 Гигабайт. В виртуальном CD-приводе такой машины будет смонтирован установочный образ ubuntu_server.iso (конечно, этот образ надо предварительно скачать), который, как обычно, нужен для установки ОС на свежесозданную виртуалку.

Впрочем, если Вы выполните такую команду, то увидите как у вас запустилось графическое окно с VNC-клиентом, который подключается к виртуальной консоли виртуальной машины. В этом окне Вы увидите начало установки Ubuntu Server 18.04. Конечно, реальный человек бы смог протыкать несколько клавиш на клавиатуре и установить Ubuntu Server, но мы лишены такой роскоши, ведь мы работаем исключительно консольными командами.

Но наше положение не такое уж и безвыходное, ведь установить ОС на виртуальную машину можно и по-другому.

Создаём диск из шаблона

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

Вызов команды virt-install, приведённый выше, выполняет сразу два действия: он создаёт одновременно и машину и диск. Из-за может сложиться неверное впечатление, что эти сущности неотделимы друг от друга.

Но на самом деле никто не мешает нам отдельно создать виртуальный диск, а затем подключить его к виртуальной машине. Вы можете подготовить свой образ диска, но в этой статье мы для простоты воспользуемся уже готовым. Проект libguestfs поддерживает в свободном доступе целый репозиторий таких образов. Кроме того, в рамках этого же проекта существует утилита virt-builder, которая позволяет легко скачать нужный образ диска и доработать его "напильником" под наши нужды.

Итак, что же нам позволяет сделать virt-builder? С помощью этой утилиты мы можем на лету сформировать уже "подготовленный" диск с уже установленной Ubuntu Server. Сделать это можно так:

virt-builder ubuntu-18.04 \    --format qcow2 \    --output my_super_disk.qcow2

Что же здесь происходит? Мы говорим, что хотели бы создать диск в формате qcow2 (можно выбрать другой) и использовать в качестве основы шаблон ubuntu-18.04, который хранится в репозитории шаблонов в проекте libguestfs. Команда virt-builder скачает этот шаблон из Интернета и затем на его основе сгенерирует итоговый диск, в котором теперь будет установлен Ubuntu Server!

Ну а теперь нам остаётся создать виртуальную машину, и указать в качестве диска (импортировать) подготовленный образ my_super_disk.qcow2:

virt-install \    --import \    --name my_super_vm \    --ram 1024 \    --disk my_super_vm.qcow2

Обратите внимание, что исчез параметр --cdrom, он нам больше не нужен. Также добавился параметр --import. Этот параметр указывает, что виртуалка будет загружаться не с cdrom, а с виртуального диска (то есть это влияет на Bios Boot Options виртуальной машины). Ну а т.к. диск у нас теперь содержит установленный Ubuntu Server, такая загрузка пройдёт успешно.

Попробуйте выполнить эти команды и создать таким образом виртуальную машину my_super_vm. Вы сможете убедиться, что Ubuntu Server 18.04 действительно уже установлен и успешно загружается.

Соединяем сетью виртуалку и хост

Вот так вот мы практически незаметно научились автоматически устанавливать виртуалки и даже раскатывать на них готовую ОС. Теперь настало время поговорить о канале управления виртуалкой после её установки и настройки.

Ещё раз хотелось бы отметить, что эталоном автоматизации системных тестов должна выступать автоматизация действий человека: как он нажимает на клавиши, кликает мышкой и совершает другие действия. И ещё раз напомним, что это очень сложный (хоть и правильный) путь. Мы же воспользуемся тем фактом, что нам не требуется взаимодействовать с GUI, нам пока вполне хватит возможности выполнения произвольных bash-команд на гостевой системе.

Для этого существуют разные подходы, но мы с Вами в этой статье рассмотрим только самый простой и, в некоторой степени, топорный вариант: установка SSH-соединения между хостом и виртуалкой.

Для этого нам потребуется сделать несколько манипуляций:

1. Создать виртуальную сеть между хостом и виртуалкой;
2. Настроить сетевой интерфейс на виртуалке;
3. Задать пароль от пользователя root на виртуалке;
4. Подредактировать SSH-настройке на виртуалке, чтобы можно было соединяться по SSH от имени рута с помощью пароля.

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

1. Создать виртуальную сеть;
2. Подключить виртуалку к этой сети (хост уже будет подключен к сети по-умолчанию).

Итак, поехали.

Для создания виртуальной сети мы воспользуемся ещё одной утилитой virsh, которая работает поверх ещё одной замечательной библиотеки libvirt.

В libvirt для создания различных виртуальных объектов (дисков, сетей, виртуалок) используются XML-схемы. XML-схема для создания сети выглядит примерно так:

<network>    <name>net_for_ssh</name>    <bridge name='net_for_ssh'/>    <ip address='192.168.100.1' netmask='255.255.255.0'/></network>

Где 192.168.100.1 это адрес, присваиваемый сетевому интерфейсу, который будет автоматически создан на хосте и ассоциирован с новой виртуальной сетью.

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

virsh net-define net_for_ssh.xml

После создания сеть создаётся в выключенном состоянии, поэтому её ещё надо включить:

virsh net-start net_for_ssh

Теперь надо подключить виртуалку к свежесозданной сети. Для этого при создании виртуалки необходимо добавить параметр --network:

virt-install \    --import \    --name my_super_vm \    --ram 1024 \    --disk my_super_vm.qcow2 \    --network network=net_for_ssh \    --noautoconsole

Обратите также внимание на аргумент --noautoconsole, который отключает автоматическое подключение к консоли виртуалки через VNC-клиент (впрочем, если Вам всё-равно хочется зайти посмотреть на виртуалку, Вы можете воспользоваться virt-manager).

Соединение готово, но пропинговать с хоста нашу виртуалку мы всё ещё не можем: сетевой интерфейс пока не настроен.

Настройка сетевого интерфейса на виртуалке

Как же мы будем настраивать интерфейс внутри виртуалки, если мы пока не можем выполнять на ней никаких команд (SSH-канал ведь ещё не настроен)? В этом нам снова поможет библиотека libguestfs и утилита virt-builder.

Дело в том, эта библиотека позволяет, в числе прочего, копировать файлы на виртуальный диск. Как мы знаем, в Ubuntu Server 18.04 за сетевые настройки отвечает netplan, и для того, чтобы сконфигурировать сетевой интерфейс, нам достаточно подложить специальный .yaml файлик в каталог /etc/netplan. И сделать это можно с помощью той же утилиты virt-builder с помощью параметра --copy-in:

network:  version: 2  renderer: networkd  ethernets:    ens3:      addresses:        - 192.168.100.2/24

virt-builder ubuntu-18.04 \    --format qcow2 \    --output my_super_disk.qcow2 \    --copy-in netcfg_ssh.yaml:/etc/netplan/

И теперь при создании виртуального диска после раскатывания Ubuntu Server 18.04 из шаблона virt-builder дополнительно скопирует файл netcfg_ssh.yaml и подложит его в директорию /etc/netplan/ на файловой системе виртуального диска.

Теперь виртуальная машина должна пинговаться, проверим:

ping 192.168.100.2 -c5

Почти всё сделали, осталось лишь настроить SSH.

Настраиваем SSH на виртуалке

Для создания канала управления виртуалкой осталось сделать совсем чуть чуть:

1. Прописать пароль для root-пользователя в виртуалке;
2. Создать ключи на виртуалке для SSH-сервера чтобы он стартовал без ругани;
3. Прописать в конфиг SSH-сервера возможность подключаться от имени рута с использованием пароля.

Начнём с пароля для root. Здесь нас снова выручает virt-builder, который, на самом деле, позволяет Вам делать с виртуальным диском поистине удивительные вещи, одна из которых прописать пароль для root-пользоавтеля:

virt-builder ubuntu-18.04 \    --format qcow2 \    --output my_super_disk.qcow2 \    --root-password password:1111 \    --copy-in netcfg_ssh.yaml:/etc/netplan/

Теперь осталось сгенерировать ключи для SSH и подправить конфиг. Для этого нам надо всего-то надо выполнить пару команд:

ssh-keygen -Ased -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config

Вот только вопрос, а как же нам выполнить эти команды? Ведь virt-builder работает только с образами дисков, никаких виртуальных машин на этом этапе не создаётся. Однако, уvirt-builder есть ещё пара козырей в рукаве. Он позволяет запускать программы гостевой системы без запуска собственно гостевой системы с помощью параметра --run-command:

virt-builder ubuntu-18.04 \    --format qcow2 \    --output my_super_disk.qcow2 \    --root-password password:1111 \    --run-command "ssh-keygen -A" \    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \    --copy-in netcfg_ssh.yaml:/etc/netplan/

И теперь всё! Канал настроен! Можно было бы даже попробовать подключиться, если бы не одно "но". После выполнения команды virt-install виртуалка только только начинает включаться. Между моментом включения виртуалки и запуском на ней ssh сервера может пройти несколько секунд. Поэтому нам потребуется организовать незатейливый механизм ожидания ssh сервера:

#!/bin/bashSSH_CMD="sshpass -p 1111 ssh -o StrictHostKeyChecking=no"while ! $SSH_CMD root@192.168.100.2 echo Hello world from my super vm!do    echo "Waiting for client VM ..."    sleep 1done

Также, мне пришлось добавить параметр -o StrictHostKeyChecking=no к команде ssh для того, чтобы запрос на добавление сервера в список доверенных серверов не блокировал выполнение скрипта. Так же мне пришлось воспользоваться утилитой sshpass для того, чтобы автоматизировать ввод пароля.

Итоги

В первой части статьи мы пока не написали ни одного реального системного теста, зато познакомились с серьёзным арсеналом утилит по работе с виртуальными машинами, научились автоматически создавать виртуалки, раскатывать на них ОС, настраивать их, а также налаживать канал управления по SSH. С этим запасом знаний мы теперь можем смело переходить к самому главному и интересному: как же, всё-таки, автоматизировать системные тесты на виртуалках.

Это вторая часть статьи, посвященной автоматизации системного тестирования на основе виртуальных машин. Первую часть можно найти здесь: http://personeltest.ru/aways/habr.com/ru/post/520310/

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

Итак, в прошлой части мы запаслись внушительным арсеналом из навыков работы с виртуальными машинами из командной строки: научились устанавливать виртуалки, раскатывать на них ОС (на примере Ubuntu Server 18.04), соединять виртуалку с хостом по сети и даже организовывать канал управления через SSH. Всё это нам пригодится в этой статье, но прежде чем перейти к практике, нужно обсудить несколько вопросов.

Что же мы хотим получить?

Самый главный вопрос, на который нужно дать ответ это "Какой результат мы хотим получить?". Да, в прошлый раз мы много говорили об автоматизации установки, развертывания и настройки виртуалок, но в отрыве от конечной цели это всё не имеет большого смысла.

Лично для меня системные тесты "всё в одном" выглядят так: я скачиваю из VCS несколько небольших файликов (сам скрипт с запуском, плюс, возможно, несколько вспомогательных артефактов), подкладываю куда нужно тестируемую программу (в виде инсталлятора или пакета, например), нажимаю одну кнопку и иду пить кофе. Когда я возвращаюсь, я хочу либо увидеть что все тесты прошли, либо что такие-то тесты сломались. Я не хочу заниматься какой-либо настройкой стенда, не хочу разворачивать виртуалки или что-то там настраивать. Хочу скачать скрипт и воспользоваться им.

Более того, этот скрипт должен быть повторно используемым: если я подложу новую сборку программы, я хочу снова запустить скрипт и он должен без вопросов снова отработать. В идеале скрипт должен кешировать промежуточные результаты, чтобы мне не приходилось каждый раз ждать пока создадутся и настроятся виртуалки (ведь эти действия должны выполниться только один раз).

Также было бы неплохо получить ещё один скрипт, который бы позволял при необходимости очистить все созданные сущности и освободить место на диске.

Что будем тестировать

Для статьи в качестве подопытной программы я выбрал интересную кандидатуру. Мы будем тестировать мини-фаервол, написанный с ипользованием библиотеки Data Plane Development Kit (DPDK). Если вы не знакомы с DPDK не пугайтесь, мы не собираемся его изучать, мы возьмём готовое приложение из тех примеров, которые поставляются вместе с DPDK. Приложение на DPDK идеально подходит к этой статье, потому что совершенно непонятно, как именно можно автоматизировать end-to-end тесты для таких приложений.

Само приложение имеет очень простой принцип работы:

1. оно принимает сетевые пакеты с одного из сетевых интерфейсов;
2. сопоставляет полученный пакет со списком правил фильтрации;
3. если пакет попал под правило DROP то пакет отбрасывается;
4. если пакет попал под правило ACCEPT то пакет выплёвывается из другого сетевого адаптера;

Соответственно, нам нужно проверить, что:

• приложение устанавливается на ОС и успешно запускается;
• правила фильтрации отрабатывают так, как и было задумано;

План работ

Как и в предыдущей части, давайте для начала представим, какие действия нам нужно было бы проделать вручную, если бы мы хотели протестировать такой базовый фаерволл с использованием виртуалок:

1. Создать три виртуальных машины (client, middlebox, server), установить везде Ubuntu Server 18.04 (например);
2. Создать две виртуальные сети: сеть между client и middlebox (назовём эту сеть для краткости net_1) и сеть между middlebox и server (назовём её net_2);
3. Подключить машины к этим сетям;
4. Настроить виртуальные машины, привести их в боевое состояние;
5. Установить наше приложение-фаервол в машину middlebox;
6. Прогнать сами тесты.

Вот все эти вещи мы и хотим автоматизировать в нашем скрипте. При этом добавим пару оговорок:

1. Как мы помним из первой части статьи, для выполнения команд на виртуалках нам потребуется организовать SSH-канал управления между виртуалками и хостом, это будет один из пунктов, который нам нужно будет дополнительно сделать, хотя для ручного тестирования этот пункт явно необязателен;
2. Хоть теоретически хост может связаться с виртуалкой по SSH используя виртуальные сети net_1 и net_2, но лучше использовать для этого отдельную сеть (назовём её net_for_ssh). Глобальных причин для этого две:

• Т.к. мы тестируем фаерволл, то не хотелось бы, чтобы управляющий трафик оказывал какое-либо влияние на ход проведения тестов;
• В случае, если что-то пойдет не так (например, фаерволл свалится), мы бы не хотели чтобы управление у виртуалки отваливалось.

За работу!

Для тестирования мини-фаерволла мы развернём такой стенд:

С учётом знаний, которые мы получили в предыдущей части статьи, автоматизировать развёртывание стенда совсем несложно:

#!/bin/bashset -euo pipefail# =======================================# Подготовка сети net_for_ssh# =======================================virsh net-define net_for_ssh.xmlvirsh net-start net_for_ssh# =======================================# Подготовка сети net_1# =======================================virsh net-define net_1.xmlvirsh net-start net_1# =======================================# Подготовка сети net_2# =======================================virsh net-define net_2.xmlvirsh net-start net_2# =======================================# Подготовка машины client# =======================================virt-builder ubuntu-18.04 \    --format qcow2 \    --output client.qcow2 \    --install wget \    --root-password password:1111 \    --run-command "ssh-keygen -A" \    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \    --copy-in netcfg_client.yaml:/etc/netplan/virt-install \    --import \    --name client \    --ram 1024 \    --disk client.qcow2 \    --network network=net_for_ssh \    --network network=net_1,mac=52:54:56:11:00:00 \    --noautoconsole# =======================================# Подготовка машины middlebox# =======================================virt-builder ubuntu-18.04 \    --format qcow2 \    --output middlebox.qcow2 \    --install python,daemon,libnuma1 \    --root-password password:1111 \    --run-command "ssh-keygen -A" \    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \    --copy-in netcfg_middlebox.yaml:/etc/netplan/virt-install \    --import \    --name middlebox \    --vcpus=2,sockets=1,cores=2,threads=1 \    --cpu host \    --ram 2048 \    --disk middlebox.qcow2 \    --network network=net_for_ssh \    --network network=net_1,model=e1000 \    --network network=net_2,model=e1000 \    --noautoconsole# =======================================# Подготовка машины server# =======================================virt-builder ubuntu-18.04 \    --format qcow2 \    --output server.qcow2 \    --install nginx \    --root-password password:1111 \    --run-command "ssh-keygen -A" \    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \    --copy-in netcfg_server.yaml:/etc/netplan/virt-install \    --import \    --name server \    --ram 1024 \    --disk server.qcow2 \    --network network=net_for_ssh \    --network network=net_2,mac=52:54:56:00:00:00 \    --noautoconsole# =======================================# Убедимся, что наши машины запустились# и доступны для команд управления# =======================================SSH_CMD="sshpass -p 1111 ssh -o StrictHostKeyChecking=no"while ! SSH_CMD root@192.168.100.2 "echo Hello world from client!" echodo    echo "Waiting for client VM ..."    sleep 1donewhile ! SSH_CMD root@192.168.100.3 "echo Hello world from middlebox!" echodo    echo "Waiting for middlebox VM ..."    sleep 1donewhile ! SSH_CMD root@192.168.100.4 "echo Hello world from server!" echodo    echo "Waiting for server VM ..."    sleep 1done

Для запуска этого скрипта потребуются следующие артефакты:

<network>    <name>net_for_ssh</name>    <bridge name='net_for_ssh'/>    <ip address='192.168.100.1' netmask='255.255.255.0'/></network>

<network>    <name>net_1</name>    <bridge name='net_1'/>    <ip address='192.168.101.1' netmask='255.255.255.0'/></network>

<network>    <name>net_2</name>    <bridge name='net_2'/>    <ip address='192.168.102.1' netmask='255.255.255.0'/></network>

network:  version: 2  renderer: networkd  ethernets:    ens3:      addresses:        - 192.168.100.2/24    ens4:      addresses:        - 192.168.101.2/24      gateway4: 192.168.101.3

network:  version: 2  renderer: networkd  ethernets:    ens3:      addresses:        - 192.168.100.3/24

network:  version: 2  renderer: networkd  ethernets:    ens3:      addresses:        - 192.168.100.4/24    ens4:      addresses:        - 192.168.102.2/24      gateway4: 192.168.102.3

Большая часть команд и приёмов Вам должна быть уже известна из первой части статьи, а мы лишь остановимся на некоторых интересных моментах:

1. Мы используем параметр --install команды virt-builder, чтобы установить на виртуалки дополнительные пакеты. Это просто удобное сокращение для --run-command "apt install ...". Собственно, Вам даже не обязательно знать, какой пакетный менеджер работает на гостевой системе virt-builder сам разберётся. Для машины client мы устанавливаем пакеты wget, для server nginx (чтобы тестировать фаерволл с помощью http-запросов на сервер). Для middlebox мы устанавливаем зависимости, необходимые для настройки и запуска DPDK-приложений;
2. Для машин client и server мы указываем, какие МАС-адреса нужно присвоить сетевым адаптерам, смотрящих в сторону фаерволла. Это пригодится нам при прогоне тестов;
3. Для машины middlebox мы указываем топологию виртуального процессора (параметр --vcpus): нам требуется один CPU c двумя ядрами без поддержки технологии hyperthreading. Два ядра это минимальное количество ядер, необходимое для запуска DPDK приложения. Кроме того мы указываем параметр --cpu host, что означает, что процессор на вируалке должен иметь те же возможности, что и процессор на хостовой системе. Дело в том, что по-умолчанию QEMU создаёт виртуальный процессор, который не поддерживает даже SSE3 инструкции. А без этого, опять же, DPDK приложение не запустится.
4. Также для машины middlebox мы указываем модель сетевых адаптеров, участвующих в машрутизации и фильтрации трафика: e1000. Та модель адаптера, которая создаётся по-умолчанию на данный момент не поддерживается библиотекой DPDK.

На текущий момент наш скрипт run_tests.sh сможет корректно отработать только один раз (или даже вообще ни разу, если Вы проделывали у себя шаги из первой части статьи). При повторном запуске у Вас будут возникать ошибки, связанные с двумя моментами:

1. Нельзя повторно создать уже созданную сеть;
2. Нельзя повторно создать уже созданную виртуальную машину.

Для того, чтобы нам было проще дорабатывать скрипт run_tests.sh, нам нужно создать скрипт, который будет удалять все наши наработки. Выглядеть этот скрипт будет так:

#!/bin/bashset -euo pipefail# =======================================# Удаление машины client# =======================================if virsh list --all | grep -q " client "; then    if virsh domstate client | grep -q "running"; then        virsh destroy client    fi    virsh undefine client --snapshots-metadata --remove-all-storagefi# =======================================# Удаление машины middlebox# =======================================if virsh list --all | grep -q " middlebox "; then    if virsh domstate middlebox | grep -q "running"; then        virsh destroy middlebox    fi    virsh undefine middlebox --snapshots-metadata --remove-all-storagefi# =======================================# Удаление машины server# =======================================if virsh list --all | grep -q " server "; then    if virsh domstate server | grep -q "running"; then        virsh destroy server    fi    virsh undefine server --snapshots-metadata --remove-all-storagefi# =======================================# Удаление сети net_for_ssh# =======================================if virsh net-list --all | grep -q " net_for_ssh "; then    if virsh net-list --all | grep " net_for_ssh " | grep -q " active "; then        virsh net-destroy net_for_ssh    fi    virsh net-undefine net_for_sshfi# =======================================# Удаление сети net_1# =======================================if virsh net-list --all | grep -q " net_1 "; then    if virsh net-list --all | grep " net_1 " | grep -q " active "; then        virsh net-destroy net_1    fi    virsh net-undefine net_1fi# =======================================# Удаление сети net_2# =======================================if virsh net-list --all | grep -q " net_2 "; then    if virsh net-list --all | grep " net_2 " | grep -q " active "; then        virsh net-destroy net_2    fi    virsh net-undefine net_2fi

Вот этот скрипт, в отличие от run_tests.sh, будет отрабатывать всегда. Основные моменты в этом скрипте:

1. Удаляет машины или сети только если они созданы (существование виртуалок проверяется с помощью команды virsh list --all, а существование сетей с помощью команды virsh net-list -all);
2. Чтобы удалить машину/сеть, сначала нужно убедиться, что эта машина/сеть выключена, иначе удалить её не получится;
3. Виртуалки удаляются вместе со снепшотами (параметр --snapshots-metadata) и подключенными дисками (параметр --remove-all-storage).

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

Здесь стоит упомянуть один неприятный момент. Когда мы запускаем SSH-команды SSH добавляет публичный ключ виртуалки в файл ~/.ssh/known_hosts. Если мы удалим виртуалки, создадим её заново и попробуем поключится к ней по SSH он откажется подключаться, думая, что Вас кто-то хочет обмануть. Мы можем избежать этой ситуации подкорректировав нашу переменную SSH_CMD:

SSH_CMD="sshpass -p 1111 ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR"

Я добавил параметр -o UserKnownHostsFile=/dev/null, чтобы запуск скрипта тестового сценария никак не влиял на хостовую машину.

Немного об организации тестов

В прошлой части я упомянул, что идеальный вариант автоматизации системных тестов это автоматизация действий человека при работе за компьютером. Но работу пользователя с Ubuntu Server (без GUI) можно представить как последовательность выполнения bash-команд, чем мы и воспользовались.

В рамках тестов мы собираемся запускать относительно много bash-команд, причём на разных виртуалках. Давайте продумаем пару моментов, прежде чем приступать к делу.

Во-первых, сделаем очень простую, но в тоже время очень полезную вещь:

EXEC_CLIENT="$SSH_CMD root@192.168.100.2"EXEC_MIDDLEBOX="$SSH_CMD root@192.168.100.3"EXEC_SERVER="$SSH_CMD root@192.168.100.4"

Мы всего лишь объявили три переменные. Но это уже позволяет писать более читабельный скрипт. Например:

$EXEC_CLIENT echo hello from client$EXEC_SERVER echo hello from server

Во-вторых, что насчёт многострочных команд? Здесь нам поможет такая возможность bash-интерпретатора как Heredoc. Heredoc позволяет нам записывать тестовые сценарии в следующим виде:

$EXEC_CLIENT << EOF    echo hello from client    ls    pwdEOF$EXEC_MIDDLEBOX << EOF    echo hello from middlebox    some_another_commandEOF

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

Когда вы используете мультистрочные команды, скорее всего вы захотите добавить в начало строчку set -xeuo pipefail. Например:

$EXEC_MIDDLEBOX << EOF    set -xeuo pipefail    command1    command2 | command3EOF

Напомню на всяких случай, что означает эта команда:

• параметр -x заставляет bash-интерпретатор печатать каждую команду перед тем как её выполнить;
• параметр -e останавливает выполнение всего скрипта, если хотя бы одна из команд завершилась с ошибкой;
• параметр -u останавливает выполнение всего скрипта, если Вы обратились в нём к несуществующей переменной;
• парамерт -o pipeline останавливает конвейер, если какая-то команда в его составе завершилась с ошибкой.

Таким образом, если что-то пойдёт не так в Вашем тестовом сценарии Вы сразу об этом узнаете.

И последний момент, на который я хотел бы обратить внимание. Иногда в таких bash-тестах Вам нужно проверить, что какая-то команда выполняется именно с ошибкой. Это можно сделать следующим образом:

$EXEC_MIDDLEBOX << EOF    set -xeuo pipefail    command1    ! command2EOF

Вышеприведенный скрипт выполнится успешно только в одном единственном случае: если command1 вернёт 0, а command2 вернёт значение, отличное от нуля.

Переходим к самим тестам

В рамках статьи мы напишем три системных теста:

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

Давайте взглянем на первый тест:

$SCP_CMD l3fwd-acl-1.0.0.deb root@192.168.100.3:~$EXEC_MIDDLEBOX << EOF    set -xeuo pipefail    dpkg -i l3fwd-acl-1.0.0.deb    echo 256 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages    mkdir -p /mnt/huge    mount -t hugetlbfs nodev /mnt/huge    modprobe uio_pci_generic    dpdk-devbind --bind=uio_pci_generic ens4 ens5    echo "R0.0.0.0/0 192.168.102.0/24 0 : 65535 0 : 65535 0x0/0x0 1" > /etc/rule_ipv4.db    echo "R0.0.0.0/0 192.168.101.0/24 0 : 65535 0 : 65535 0x0/0x0 0" >> /etc/rule_ipv4.db    echo "R0:0:0:0:0:0:0:0/0 0:0:0:0:0:0:0:0/0 0 : 65535 0 : 65535 0x0/0x0 0" > /etc/rule_ipv6.db    daemon --name l3fwd --unsafe --output /var/log/l3fwd -- l3fwd-acl \        -l 1 \        -n 4 \        -- \        -p 0x3 \        -P \        --config="(0,0,1),(1,0,1)" \        --rule_ipv4="/etc/rule_ipv4.db" \        --rule_ipv6="/etc/rule_ipv6.db"EOF

Посмотрите, какие манипуляция с окружением нам приходится делать чтобы проверить приложение DPDK с точки зрения конечного пользователя:

1. Установить пакет .deb в систему;
2. Подправить параметры ядра;
3. Смонтировать раздел к файловой системе;
4. Загрузить модуль ядра;
5. Привязать сетевые интерфейсы, участвующие в маршрутизации, к драйверу uio_pci_generic;
6. Запустить приложение в фоне.

В этом и состоит сущность системного тестирования: мы не просто тестируем программу "в вакууме", мы не делаем никаких заглушек и ухищрений чтобы она хоть как-то заработала. Вместо этого мы помещаем программу в реальную обстановку и производим все манипуляции, которые пришлось бы сделать на реальном компьютере реальному пользователю. Это даёт колоссальный уровень спокойствия за тестируемую программу.

И этот лейтмотив только усиливается во втором тесте: вместо того, чтобы проверять работу DPDK-приложения с помощью фиксированного набора пакетов (как это можно было бы сделать в unit-тестах, например), мы будем проверять приложение так, как это бы сделал реальный человек: попробуем передать что-нибудь по сети с помощью реальных утилит и посмотрим на результат:

$EXEC_CLIENT arp -s 192.168.101.3 52:54:56:00:00:00$EXEC_SERVER arp -s 192.168.102.3 52:54:56:11:00:00$EXEC_CLIENT << EOF    set -xeuo pipefail    ping -c 5 192.168.102.2    wget --timeout=5 --tries=1 http://192.168.102.2EOF

Третий же тест довольно очевиден и вытекает из первых двух:

# =======================================# Добавим правило, заврещающее tcp трафик# =======================================$EXEC_MIDDLEBOX << EOF    set -xeuo pipefail    daemon --name l3fwd --stop    # Это и есть запрещающее правило    echo "@0.0.0.0/0 0.0.0.0/0 0 : 65535 0 : 65535 0x06/0xff" > /etc/rule_ipv4.db    echo "R0.0.0.0/0 192.168.102.0/24 0 : 65535 0 : 65535 0x0/0x0 1" >> /etc/rule_ipv4.db    echo "R0.0.0.0/0 192.168.101.0/24 0 : 65535 0 : 65535 0x0/0x0 0" >> /etc/rule_ipv4.db    daemon --name l3fwd --unsafe --output /var/log/l3fwd -- l3fwd-acl \        -l 1 \        -n 4 \        -- \        -p 0x3 \        -P \        --config="(0,0,1),(1,0,1)" \        --rule_ipv4="/etc/rule_ipv4.db" \        --rule_ipv6="/etc/rule_ipv6.db"EOF# =======================================# Проверяем, что ping продолжает ходить,# а http трафик - перестал# =======================================$EXEC_CLIENT << EOF    set -xeuo pipefail    ping -c 5 192.168.102.2    ! wget --timeout=5 --tries=1 http://192.168.102.2EOF

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

Дорабатываем скрипт run_tests.sh

С самими тестами мы разобрались, осталось немного подумать над нашим скриптом по запуску тестов, который сейчас может успешно отрабатывать только при предварительном прогоне скрипта run_clean.sh.

Давайте поразмышляем вот над чем: весь скрипт можно условно разделить на две больших секции: до копирования сборки DPDK-приложения на middlebox и после. В чём разница? Дело в том, что по отношению к стенду (системе из виртуальных машин) сборка DPDK-приложения является внешней переменной Х. Мы заранее знаем, как поведёт себя скрипт до появления этой внешней переменной, но мы не знаем насколько успешно пройдут тесты после внедрения внешнего неизвестного элемента. Вдруг сборка окажется неработоспособной и тесты свалятся?

Поэтому мы можем внести элемент кеширования в наш скрипт. Как насчёт фиксации результатов работы скрипта на момент ровно перед появлением внешней переменной, и отката к этому состоянию при повторном запуске скрипта? Ведь мы знаем, что участок скрипта до появления неопределённого элемента должен всегда выполняться одинаково. А фиксацию можно сделать очень просто: мы можем создать снепшот, например с названием init, для каждой виртуальной машины после её первоначальной настройки.

Осталось лишь немного подправить скрипт чтобы он учитывал эту новую логику:

# =======================================# Подготовка машины client# =======================================if ! virsh list --all | grep -q " client "then    virt-builder ubuntu-18.04 \        --format qcow2 \        --output client.qcow2 \        --hostname client \        --install wget,net-tools \        --root-password password:1111 \        --run-command "ssh-keygen -A" \        --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \        --copy-in netcfg_client.yaml:/etc/netplan/    virt-install \        --import \        --name client \        --ram 1024 \        --disk client.qcow2 \        --network network=net_for_ssh \        --network network=net_1,mac=52:54:56:11:00:00 \        --noautoconsole    virsh snapshot-create-as client --name initelse    virsh snapshot-revert client --snapshotname initfi

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

Для сетей же достаточно просто добавить проверку, чтобы создавать их только в том случае, если они не существуют:

# =======================================# Подготовка сети net_1# =======================================if ! virsh net-list --all | grep -q " net_1 "then    virsh net-define net_1.xml    virsh net-start net_1fi

Вот и всё, теперь наш скрипт мало того, что запускается каждый раз без особых проблем, так ещё и экономит нам значительное количество времени на повторных запусках за счёт кеширования процесса подготовки стенда. Ну а Вас остаётся только поздравить: ведь теперь Вы умеете создавать настоящие системные тесты с использованием виртуалок!

Репо с итоговым скриптом можно найти здесь: https://github.com/testo-lang/testo-articles/tree/master/01

Итоги

Что ж, мы проделали довольно много работы, в том числе и муторной, и самое время оглянуться назад и посмотреть, чего же мы достигли. А достигли мы немалого: мы написали скрипт, который в автоматическом режиме полностью с нуля разворачивает у нас на компьютере стенд из трёх виртуальных машин, раскатывает на этом стенде сборку тестируемого приложения, а также прогоняет настоящие системные (end-to-end) тесты для этого приложения.

Заметьте, что эти тесты проверяют работу нашего приложения от начала и до конца именно в том виде, в котором это приложение будет в реальности работать: мы поместили DPDK-приложение в конкретную среду (стенд из трех машин Ubuntu Server 18.04) и с конкретным набором реальных пользовательских проверок (вызов утилиты ping и wget). В нашем стенде нет ни единой заглушки, мы можем взять наш .deb пакет и прямо сейчас выложить его на сайте для скачивания всеми желающими. И именно поэтому такие тесты дают такую четкую уверенность, что если программа работает внутри тестов, то она точно отработает в реальных условиях (по крайней мере, в ТАКИХ ЖЕ реальных условиях). И эта уверенность дорогого стоит.

Но это ещё не всё: все наши артефакты это два скрипта (run_tests.sh и run_clean.sh), три xml-файла и три yaml-файла. Всё это текстовые файлы и идеально хранятся в любой VCS. Эти скрипты можно легко переносить между компьютерами и всё равно прогонять тесты одной кнопкой.

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

Ну а если у Вас осталось некоторое ощущение "недоделанности", "костыльности" и "кривизны" подхода, который мы продемонстрировали в этой статье, то Вы, на самом деле, будете правы. Все эти наработки очень даже хороши как Proof Of Concept для идеи автоматизации системных тестов с использованием виртуальных машин. Но строить полноценную большую и промышленную систему тестов на основе баш-скриптов было бы довольно оптимистично. Впрочем, есть и более элегентное, законченное и отработаное решение, которое может помочь Вам клепать системные тесты как горячие пирожки на любых операционных системах и даже не задумываться всерьез обо всей сложной внутренней кухне, которая при всём при этом происходит. Но это уже тема для нашей следующей статьи...

Что мы хотим от удобной Test Management System?

• Удобная установка и поддержка.
• Удобный и понятный интерфейс.
• Создание и управление проектами.
• Создание пользователей и проектных ролей для пользователей.
• Удобная интеграция с автоматическими тестами.
• Создание тест-плана.
• Создание тест-кейса.
• Создание чек-листа.
• Создание общего шага
• Версионирование тест-кейса/чек-листа.
• Создание пользовательских атрибутов/конфигураций.
• Прогон тест-кейса/чек-листа.
• Понятная система отчётности.
• Встроенная система баг-трекинга.
• Возможность оповещения коллег внутри и вне системы.
• Возможность интеграции с другими инструментами.

Зачем нужна TMS?

1. Самый дешёвый способ не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.
2. Другой способ использовать одну из популярных TMS-ок, интегрированную с баг-трекером компании.
3. Next-level способ выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.

Популярные системы управления тестированием на 2020 г

• ALM Octane
• Test IT
• TestRail
• Zephyr
• TM4J
• Qase
• PractiTest
• Testuff
• Azure
• MTM TFS
• Kualitee

1. ALM Octane

• Общий доступ к библиотекам требований и ресурсов
• Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям
• Быстрый доступ к показателям, например к данным о не устранённых дефектах
• Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile
• Работа с автоматизированными тестами
• Вебхуки
• Удобная система отчетов
• Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения
• Аналитика на любой вкус и цвет: гибко настраиваемые отчёты
• Интеграция с 50+ инструментами

2. Test IT

• Управление тест-планами, тест-кейсами и чек-листами
• Общие шаги для повторяющихся действий
• Создание пользовательских атрибутов/конфигураций
• Автоматическое распределение тестов на QA инженеров
• Интеграция автоматических тестов с помощью API
• Создание тест-ранов вне системы с дальнейшим управлением состояния
• Аналитика как по автоматическим, так и по ручным тестам
• Внутренний чат и вебхуки во внешние системы
• Ролевая модель и персонализация
• Геймификация
• Двусторонняя интеграция с JIRA
• Расширенная функциональность API
• Импорт из других систем управления тестированием

3. TestRail

• Отслеживание состояния и результатов отдельного теста
• Сравнение результатов нескольких тестов, конфигураций и этапов
• Типизация проектов для ведения тестовой документации
• Внутренний чат и оповещения во внешнюю систему
• Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов
• Развёрнутые отчёты и метрики
• Широкие возможности настройки, облачные или локальные варианты установки
• Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio
• Удобный REST API

4. Zephyr

• Ссылка на user-stories, задачи, требования, дефекты
• Конфигурации деплоя: в облаке, на сервере, в дата-центре
• Расширенная информация на дашбордах аналитики и DevOps
• Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo
• Автоматизированные тесты
• Создание пользовательских атрибутов
• Понятная система отчетов.

5. TM4J

• Линкование тестовых сценариев и issue не выходя из JIRA
• Работа с автоматизированными тестами
• Внутренний багтрекер
• Понятная система отчетов
• Использование общего шага
• Фактическое время прохождения теста
• Экспорт данных в Excel

6. Qase

• Тестовый репозиторий: выстраивание тестов в логические группы
• Составление шагов для кейсов, установка приоритета и серьёзности
• Запуск тестовых прогонов с трекингом времени по каждому тест
• Хранение документации по проекту
• Автоматическое заведение дефектов в интегрированные трекеры
• Интеграция с JIRA, Redmine, YouTrack и Slack
• Объединение результатов автотестов с REST API

7. PractiTest

• Лёгкое добавление тестов новых фич в регрессионное тестирование
• Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные
• Различное отображение информации для разных групп пользователей
• Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на прод
• Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack

8. Testuff

• Планирование тестов
• Интуитивный drag-n-drop интерфейс
• Наглядные отчёты с подробными графиками
• Два способа интеграции со сторонними инструментами баг-трекинга
• Возможность тестировать с любого девайса

9. Azure DevOps Server

• Интеграция с любым продуктом компании Microsoft
• Нативный интерфейс
• Интеграция с любым CI/CD
• Ведение удобных Dashboards
• Работа с автотестами
• Пользовательские атрибуты

10. MTM TFS

• Исследовательское тестирование
• Планирование и выполнение ручных тестов
• Кроссплатформенные конфигурации тестов (разные версии одного теста для разных платформ/релизов)
• Диагностика прохождения теста (логи, видео и т. п.)
• Импорт-экспорт тестов
• Межпроектный импорт-экспорт тестов
• Запись и воспроизведение ручных тестов (рекордер)
• Автоматизация тестов

11. Kualitee

• Управление проектами
• Управление дефектами
• Управление тестовой документацией
• Персональная панель инструментов
• Продуманная настройка пользователей

В начале было...

Простыня

• Быстроклик в три строчки (ну ладно, в двести три) для очень маленьких проектов;
• Для примеров кода в мини-демо;
• Для первого кода в стиле хелоу ворд среди автотестов.

import com.codeborne.selenide.Condition;import com.codeborne.selenide.WebDriverRunner;import org.testng.annotations.Test;import static com.codeborne.selenide.Selenide.*;public class RandomSheetTests {    @Test    void addUser() {        open("https://ui-app-for-autotest.herokuapp.com/");        $("#loginEmail").sendKeys("test@protei.ru");        $("#loginPassword").sendKeys("test");        $("#authButton").click();        $("#menuMain").shouldBe(Condition.appear);        $("#menuUsersOpener").hover();        $("#menuUserAdd").click();        $("#dataEmail").sendKeys("mail@mail.ru");        $("#dataPassword").sendKeys("testPassword");        $("#dataName").sendKeys("testUser");        $("#dataGender").selectOptionContainingText("Женский");        $("#dataSelect12").click();        $("#dataSelect21").click();        $("#dataSelect22").click();        $("#dataSend").click();        $(".uk-modal-body").shouldHave(Condition.text("Данные добавлены."));        WebDriverRunner.closeWebDriver();    }}

PageObject

public class UsersPage {    @FindBy(how = How.ID, using = "dataEmail")    private SelenideElement email;    @FindBy(how = How.ID, using = "dataPassword")    private SelenideElement password;    @FindBy(how = How.ID, using = "dataName")    private SelenideElement name;    @FindBy(how = How.ID, using = "dataGender")    private SelenideElement gender;    @FindBy(how = How.ID, using = "dataSelect11")    private SelenideElement var11;    @FindBy(how = How.ID, using = "dataSelect12")    private SelenideElement var12;    @FindBy(how = How.ID, using = "dataSelect21")    private SelenideElement var21;    @FindBy(how = How.ID, using = "dataSelect22")    private SelenideElement var22;    @FindBy(how = How.ID, using = "dataSelect23")    private SelenideElement var23;    @FindBy(how = How.ID, using = "dataSend")    private SelenideElement save;    @Step("Complex add user")    public UsersPage complexAddUser(String userMail, String userPassword, String userName, String userGender,                                     boolean v11, boolean v12, boolean v21, boolean v22, boolean v23) {        email.sendKeys(userMail);        password.sendKeys(userPassword);        name.sendKeys(userName);        gender.selectOption(userGender);        set(var11, v11);        set(var12, v12);        set(var21, v21);        set(var22, v22);        set(var23, v23);        save.click();        return this;    }    @Step("Fill user Email")    public UsersPage sendKeysEmail(String text) {...}    @Step("Fill user Password")    public UsersPage sendKeysPassword(String text) {...}    @Step("Fill user Name")    public UsersPage sendKeysName(String text) {...}    @Step("Select user Gender")    public UsersPage selectGender(String text) {...}    @Step("Select user variant 1.1")    public UsersPage selectVar11(boolean flag) {...}    @Step("Select user variant 1.2")    public UsersPage selectVar12(boolean flag) {...}    @Step("Select user variant 2.1")    public UsersPage selectVar21(boolean flag) {...}    @Step("Select user variant 2.2")    public UsersPage selectVar22(boolean flag) {...}    @Step("Select user variant 2.3")    public UsersPage selectVar23(boolean flag) {...}    @Step("Click save")    public UsersPage clickSave() {...}    private void set(SelenideElement checkbox, boolean flag) {        if (flag) {            if (!checkbox.isSelected()) checkbox.click();        } else {            if (checkbox.isSelected()) checkbox.click();        }    }}

    @Test    void addUser() {        baseRouter.authPage()                .complexLogin("test@protei.ru", "test")                .complexOpenAddUser()                .complexAddUser("mail@test.ru", "pswrd", "TESTNAME", "Женский", true, false, true, true, true)                .checkAndCloseSuccessfulAlert();    }

    @Test    void addUserWithoutComplex() {        //Arrange        baseRouter.authPage()                .complexLogin("test@protei.ru", "test");        //Act        baseRouter.mainPage()                .hoverUsersOpener()                .clickAddUserMenu();        baseRouter.usersPage()                .sendKeysEmail("mail@test.ru")                .sendKeysPassword("pswrd")                .sendKeysName("TESTNAME")                .selectGender("Женский")                .selectVar11(true)                .selectVar12(false)                .selectVar21(true)                .selectVar22(true)                .selectVar23(true)                .clickSave();        //Assert        baseRouter.usersPage()                .checkTextSavePopup("Данные добавлены.")                .closeSavePopup();    }

А что еще бывает?

• Часто встречается паттерн ScreenPlay, о котором можно почитать например тут. У нас он не прижился, так как использовать bdd-подходы без вовлечения людей, не умеющих читать код бессмысленное насилие над автоматизаторами.
• У js-фреймворков появляются свои собственные упрощающие жизнь подходы, помимо обязательного PageObject, но при их разнообразии говорить о чем-то устоявшемся и универсальном, мне кажется, слишком смело.
• Можно написать и что-то свое, например, фреймворк на основе ModelBaseTesting, о чем хорошо рассказали в докладе с гейзенбага докладе с гейзенбага. Этот подход используется в первую очередь в проектах со сложносвязанными объектами, когда обычных тестов не хватает для проверки всех возможных комбинаций состояний и взаимодействий объектов.

Что такое Page Element?

• Клик по элементу оглавления с заданным текстом,
• Проверка существования элемента с заданным текстом,
• Проверка отступа элемента с заданным текстом.

public class UsersPage {    public Table usersTable = new Table();    public InputLine email = new InputLine(By.id("dataEmail"));    public InputLine password = new InputLine(By.id("dataPassword"));    public InputLine name = new InputLine(By.id("dataName"));    public DropdownList gender = new DropdownList(By.id("dataGender"));    public Checkbox var11 = new Checkbox(By.id("dataSelect11"));    public Checkbox var12 = new Checkbox(By.id("dataSelect12"));    public Checkbox var21 = new Checkbox(By.id("dataSelect21"));    public Checkbox var22 = new Checkbox(By.id("dataSelect22"));    public Checkbox var23 = new Checkbox(By.id("dataSelect23"));    public Button save = new Button(By.id("dataSend"));    public ErrorPopup errorPopup = new ErrorPopup();    public ModalPopup savePopup = new ModalPopup();}

    @Test    public void authAsAdmin() {        baseRouter                .authPage().email.fill("test@protei.ru")                .authPage().password.fill("test")                .authPage().enter.click()                .mainPage().logoutButton.shouldExist();    }

public class AuthSteps{    private BaseRouter baseRouter = new BaseRouter();    @Step("Sigh in as {mail}")    public BaseSteps login(String mail, String password) {        baseRouter                .authPage().email.fill(mail)                .authPage().password.fill(password)                .authPage().enter.click()                .mainPage().logoutButton.shouldExist();        return this;    }    @Step("Fill E-mail")    public AuthSteps fillEmail(String email) {        baseRouter.authPage().email.fill(email);        return this;    }    @Step("Fill password")    public AuthSteps fillPassword(String password) {        baseRouter.authPage().password.fill(password);        return this;    }    @Step("Click enter")    public AuthSteps clickEnter() {        baseRouter.authPage().enter.click();        return this;    }    @Step("Enter should exist")    public AuthSteps shouldExistEnter() {        baseRouter.authPage().enter.shouldExist();        return this;    }    @Step("Logout")    public AuthSteps logout() {        baseRouter.mainPage().logoutButton.click()                .authPage().enter.shouldExist();        return this;    }}public class BaseRouter {// Класс для создания страниц, чтобы не дублировать этот код везде, где понадобится обращение к странице    public AuthPage authPage() {return page(AuthPage.class);}    public MainPage mainPage() {return page(MainPage.class);}    public UsersPage usersPage() {return page(UsersPage.class);}    public VariantsPage variantsPage() {return page(VariantsPage.class);}}

Хранение данных

public class User {    private Integer id;    private String mail;    private String name;    private String password;    private Gender gender;    private boolean check11;    private boolean check12;    private boolean check21;    private boolean check22;    private boolean check23;    public enum Gender {        MALE,        FEMALE;        public String getVisibleText() {            switch (this) {                case MALE:                    return "Мужской";                case FEMALE:                    return "Женский";            }            return "";        }    }}

public class Users {    public static final User admin = User.builder().mail("test@protei.ru").password("test").build();}

    public static User getUserRandomData() {        User user = User.builder()                .mail(getRandomEmail())                .password(getShortLatinStr())                .name(getShortLatinStr())                .gender(getRandomFromEnum(User.Gender.class))                .check11(getRandomBool())                .check21(getRandomBool())                .check22(getRandomBool())                .check23(getRandomBool())                .build();//business-logic: 11 xor 12 must be selected        if (!user.isCheck11()) user.setCheck12(true);         if (user.isCheck11()) user.setCheck12(false);        return user;    }

Создание данных

• нажимать кнопки руками перед тестом,
• оставить данные от предыдущего теста,
• развернуть перед тестом из backup,
• создать кликами по кнопкам прямо в тесте,
• использовать API.

Добавим капельку API

public class ApiSettings {    private static String loginEndpoint="/login";    public static RequestSpecification testApi() {        RequestSpecBuilder tmp = new RequestSpecBuilder()                .setBaseUri(testConfig.getSiteUrl())                .setContentType(ContentType.JSON)                .setAccept(ContentType.JSON)                .addFilter(new BeautifulRest())                .log(LogDetail.ALL);        Map<String, String> cookies = RestAssured.given().spec(tmp.build())                .body(admin)                .post(loginEndpoint).then().statusCode(200).extract().cookies();        return tmp.addCookies(cookies).build();    }}

Класс BeautifulRest

public class BeautifulRest extends AllureRestAssured {        public BeautifulRest() {}        public Response filter(FilterableRequestSpecification requestSpec, FilterableResponseSpecification responseSpec, FilterContext filterContext) {            AllureLifecycle lifecycle = Allure.getLifecycle();            lifecycle.startStep(UUID.randomUUID().toString(), (new StepResult()).setStatus(Status.PASSED).setName(String.format("%s: %s", requestSpec.getMethod(), requestSpec.getURI())));            Response response;            try {                response = super.filter(requestSpec, responseSpec, filterContext);            } finally {                lifecycle.stopStep();            }            return response;        }}

    @Step("create user")    public static User createUser(User user) {        String usersEndpoint = "/user";        return RestAssured.given().spec(ApiSettings.testApi())                .when()                .body(user)                .post(usersEndpoint)                .then().log().all()                .statusCode(200)                .body("state",containsString("OK"))                .extract().as(User.class);    }

    public static Object create(String endpoint, Object model) {        return RestAssured.given().spec(ApiSettings.testApi())                .when()                .body(model)                .post(endpoint)                .then().log().all()                .statusCode(200)                .body("state",containsString("OK"))                .extract().as(model.getClass());    }    @Step("create user")    public static User createUser(User user) {                  create(User.endpoint, user);    }

Еще раз про рутинные операции

    @Test    void checkUserVars() {        //Arrange        User userForTest = getUserRandomData();        // Проверка корректности сохранения полей уже есть в другом тесте,  // этот тест проверяет отображение вариантов из-под залогинившегося юзера,  // поэтому не важно, как юзер создан        usersSteps.createUser(userForTest);        authSteps.login(userForTest);        //Act        mainMenuSteps                .clickVariantsMenu();        //Assert        variantsSteps                .checkAllVariantsArePresent(userForTest.getVars())                .checkVariantsCount(userForTest.getVarsCount());        //Cleanup        usersSteps.deleteUser(userForTest);    }

    @Test    void authAsAdmin() {        authSteps.login(Users.admin);// Это всё, просто авторизовались под админом. Все действия и проверки внутри. // Не очень очевидно, не правда ли? 

    @Test(dataProvider = "usersWithDifferentVars")    void checkUserDifferentVars(User userForTest) {        //Arrange        usersSteps.createUser(userForTest);        authSteps.login(userForTest);        //Act        mainMenuSteps                .clickVariantsMenu();        //Assert        variantsSteps                .checkAllVariantsArePresent(userForTest.getVars())                .checkVariantsCount(userForTest.getVarsCount());    } // Метод возвращает пользователей с полным перебором трех булевых параметров.  // Предположим, это важное бизнес-требование.    @DataSupplier(name = "usersWithDifferentVars")    public Stream<User> usersWithDifferentVars(){        return Stream.of(            getUserRandomData().setCheck21(false).setCheck22(false).setCheck23(false),            getUserRandomData().setCheck21(true).setCheck22(false).setCheck23(false),            getUserRandomData().setCheck21(false).setCheck22(true).setCheck23(false),            getUserRandomData().setCheck21(false).setCheck22(false).setCheck23(true),            getUserRandomData().setCheck21(true).setCheck22(true).setCheck23(false),            getUserRandomData().setCheck21(true).setCheck22(false).setCheck23(true),            getUserRandomData().setCheck21(false).setCheck22(true).setCheck23(true),            getUserRandomData().setCheck21(true).setCheck22(true).setCheck23(true)        );    }

Выводы

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

Всем привет! Я Максим Кузнецов, и я продолжаю цикл статей рассказом об инструменте автоматизированного тестирования в Росбанке.

В прошлый раз вы читали:

1. Fast-Unit или декларативный подход к юнит-тестам
2. Tladianta. Сервис по автоматизированному тестированию в Росбанке

Я сегодня расскажу о самом инструменте фреймворке Tladianta.

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

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

Какие задачи он должен решать?

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

Архитектура

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

Плагины предоставляют функционал и реализацию шагов для конкретного стека технологий (платформы), на которых написано тестируемое приложение.

Плагинов в семействе компонентов фреймворка пока 4:

• HTML-plugin для тестирования веб-приложений, сайтов, порталов и пр. на различных браузерах;
• Desktop-plugin для тестирования desktop-приложений, написанных на Swing, AWT, .Net и пр. языках высокого уровня, Windows-приложения, а также терминальные. Например, Bank Information System;
• Mobile-plugin для тестирования мобильных приложений на iOS/Android;
• Rest-plugin для тестирования REST API приложений любых типов.

Ассортимент и функционал плагинов может (и будет) расширяться. Плагин должен отвечать небольшим требованиям, чтобы иметь возможность работать под управлением "common".

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

Какие задачи решает:

• охват основных платформ разработки;
• простота наращивания функционала фреймворка;
• одновременное использование нескольких платформенных модулей;

Конфигурирование

Запуск тестов на выполнение, как правило, конфигурируется различными свойствами. Эти свойства имеют различные области (уровни) влияния.
Так, например, можно выделить:

Кроме того, часто нужно задать значения свойств любого уровня специально для среды запуска: DEV, TEST, CERT, а также опционально добавлять к набору свойств конфигурации группу свойств под конкретный тест или группу тестов (настройки подключения к базе данных, стороннему сервису и прочие).

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

По умолчанию конфигурация собирается следующим образом:

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

Какие задачи решает:

• легкий старт и удобство настройки;
• Возможность настройки под команду или под систему;
• гибкий механизм конфигурирования проекта с тестами;

Контекст исполнения сценария

Контекст здесь означает закешированные Java-сущности, которые устанавливаются при старте каждого сценария и обеспечивают корректное исполнение его шагов.
Контекст состоит из

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

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

Такой подход позволил заложить удобство при переходе на контекст другого проекта и использование его шагов прямо в том же самом сценарии (см. далее).

Какие задачи решает:

• возможность делиться шагами с другими командами;
• удобство e2e тестирования.

Гостевой модуль использование шагов и контекста других проектов.

Допустим, две независимые команды разрабатывают авто-тесты для двух различных приложений, создают свои уникальные шаги и java-сущности (страницы, элементы и пр.), а также переопределяют методы шагов из библиотеки фреймворка.

В своих проектах команды реализуют тестовое взаимодействие со своим тестируемым приложением клики, заполнение полей, проверки и т.д.

Повторю еще раз в банке все приложения связаны между собой и образуют IT-экосистему, и появляются сквозные сценарии, в которых нужно часть действий сделать в другом приложении. Не обложить заглушками (хотя это и правильно), а именно вживую проделать.

Я прекрасно понимаю гнев и негодование BDD-евангелистов, но что есть, то есть.

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

Для реализации такой возможности Tladianta имеет спец шаги переключения контекста.

Вот тут и пригодились те самые отложенные действия.

Сценарий при этом может выглядеть так:

Каждый проект на базе Tladianta должен иметь свойство конфигурации app.name с понятным человеку именем. Это имя идентифицирует контекст проекта и используется для переключений/установки контекста в сценарии.

В момент переключения контекста сценария будут выполнены все [отложенные] действия установки контекста, зарегистрированные для конкретного проекта.

Чтобы любой проект на базе Tladianta можно было использовать как гостевой в других проектах, он должен отвечать ряду требований:

1. проект тестирования должен быть построен на базе Tladianta-framework;
2. проект тестирования должен собираться по релизам и публиковаться в банковский репозиторий nexus;
3. проект подключается как гостевой через зависимость в POM-файле принимающего проекта. Последний стабильный релиз;
4. проект тестирования в процессе сборки релиза должен включать ресурсы с файлами свойств конфигурации.

Таким образом, все проекты тестирования объединяются в единую экосистему тестирования, подчиненную общим правилам, что значительно упрощает их поддержку силами отдела сервиса АТ, одновременно сохраняя индивидуальность каждой команды.

Какие проблемы решает:

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

Библиотека шагов.

Tladianta реализует принцип "Создай шаг один раз и переопределяй его метод, где нужно".
Шаги, составляющие библиотеку, разбиты на несколько уровней:

• общие шаги для всех проектов на базе любых плагинов;
• шаги плагина;
• шаги проекта.

Вместо классической реализации шагов cucumber Tladianta разделяет определение шага (step definition) и реализацию шага (step implementation) на две разные сущности.
Это позволило отделить формулировки шага и собрать их в библиотеку, оставив плагинам и проектам работу над реализацией конкретного поведения шага.

Таким образом, одна формулировка шага может иметь разную реализацию в разных плагинах и проектах.

Создавая сценарий, больше не нужно беспокоиться о том, что шаг "занят" в другом плагине и нужно дублировать его у себя, меняя формулировку или вставляя разные костыли в виде символов точек, лишних пробелов и так далее, чтобы избежать ошибки "Multiple step definition found".

Вместо этого нужно просто переопределить метод этого шага в своем проекте или даже на конкретной странице.

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

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

Роль сервиса АТ также позволяет нам вылавливать из оставшихся 20% шагов, которые команды делают себе сами, те шаги, которые объективно нужны многим, и мы добавляем их в библиотеку фреймворка. Автоматизаторы в командах, таким образом, принимают участие в развитии инструмента.

Какие задачи решает:

• возможность настройки под команду или под систему в части реализации шагов;
• BDD стиль в написании сценариев;
• единая библиотека шагов сценария;
• увеличение вовлеченности автоматизаторов на местах в развитие инструмента.

Тестовые данные и шаблоны генерации значений параметров шагов

Cucumber дает возможность часть текста шага использовать как параметр. Это очень удобно.
Tladianta расширяет эту возможность динамической параметризацией шагов.

Например, в шаге вам нужно использовать номер договора, дату, номер счета и прочее. Чтобы не писать все эти значения сразу в шаге, затрудняя при этом поддержку теста, можно в места параметров шага вставить шаблон автозамены, а сами значения собрать в некие файлы и поддерживать уже их.

Tladianta перед выполнением сценария все шаблоны заменит на конкретные значения из тестовых данных и в отчетах о прогоне вы увидите уже их.

В качестве источников тестовых данных могут использоваться:

• Json
• Excel
• Properties
• Mongo DB

Генераторы значений

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

Tladianta представляет очень удобный механизм генерации текстовых значений "на лету" это генераторы значений.

Работают они так же, как и шаблоны авто-замены тестовых данных, но имеют немного другой синтаксис и время срабатывания.
Генераторы значений отрабатывают уже после подстановки тестовых данных.

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

Какие проблемы решает:

• возможность настройки под команду или под систему;
• BDD стиль в написании сценариев.

Древовидная структура

Продолжаем тему длинных сквозных сценариев.
Тут есть дилемма атомарные шаги или читаемый сценарий.

Правильно это и то, и другое.

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

Обычно такие сценарии подлежат рефакторингу разбивке на части и упрощению. Беда в том, что после разбивки, такие части сами по себе теряют смысл.

Например, у нас есть сценарии из 700+ шагов. Это большие такие сквозные сценарии. В функциональных тестах отдельные части протестированы. А в этом e2e сценарии ничего не выкинуть. Только читать и поддерживать его невозможно. Что делать?

Мы сделали сценарий древовидным.

Он остается плоским с точки зрения cucumber, а вот с точки зрения человека он выглядит, как дерево. Атомарные шаги сгруппированы, а группы названы объединяющей фразой. Это такие комплексные толстые шаги, которые не шаги, их не нужно переиспользовать, т.к. они как шаги не существуют.

Например,

Комплексные действия тоже объединяются в группы, уже логические, такие бизнес-шаги.
Например,

Вы заметили, что это уже не cucumber шаги?

Это то, что понимает, скажем, аналитик, который знает назубок этот сквозной сценарий. Если сценарий упадет, он довольно быстро сможет понять, в каком месте сломалось. Ему не нужно быть для этого автоматизатором. Ему достаточно уметь открыть отчет Allure и знать русский язык.

Древовидное отображение сценария мы сделали в среде разработки и в отчете Allure.

Узлы дерева можно сворачивать и читать сценарий по верхам.

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

Какие задачи решает:

• BDD стиль в написании сценариев;
• удобство в расследовании падений и сбора результатов;
• удобство e2e тестирования.
• использование в Agile-командах

Page Object

Мы выбрали шаблон PageObject для архитектуры автотеста как основной, но не единственный. Просто он объектно-ориентированный, это так по javaвски.

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

Вкратце PageObject предполагает описание формы или экрана приложения как отдельного java-класса, а поля класса это части интерфейса формы: поля ввода, кнопки, флажки, таблицы и прочее.

В сценарии специальным шагом

объект страницы устанавливается как текущий и дальнейшие шаги работают в контексте этой страницы.

Блоки.

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

Логично выделить их в отдельную сущность и вообще разбить страницу на группы, области.

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

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

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

Блоки элементов могут быть вложены друг в друга

Блоки могут быть списками

Такая навигация очень помогает ориентироваться в сценарии и приложении.

Части пути к элементу должны быть названы так, как они выглядят на форме/странице. То есть, читая сценарий, можно сразу глазами находить элемент на экране и понимать, что куда заполняется и где нажимается.

Довольно удобно.

Какие задачи решает:

• BDD стиль в написании сценариев.
• удобство в расследовании падений и сбора результатов.
• использование в Agile командах всем просто понять сценарий

Использование нескольких плагинов в одном проекте

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

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

Самая распространенная ситуация это когда нужно результат действий через UI проверить через REST запросы к бэкенду приложения.

Какие задачи решает:

• одновременное использование нескольких платформенных модулей;

Запись видео.

Tladianta представляет конфигурируемый и настроенный "из коробки" инструмент записи видео по умолчанию, который, однако, можно переопределить или добавить свой у себя в проекте.

Перед запуском теста фреймворк запускает все зарегистрированные видео-рекордеры и по окончании сценария останавливает их.

Настройки поведения видео-рекордера (вкл/выкл, сохранять видео всегда или только при падении и пр.) можно использовать общие или добавить свои только для проекта.

Какие задачи решает:

• возможность настройки под команду или под систему.
• гибкий механизм конфигурирования проекта с тестами.
• удобство в расследовании падений.

Allure-report

По-умолчанию результаты прогона тестов логируются в Allure-отчет. Логирование поддерживает древовидную структуру сценария, если она используется. В отчет попадают также логи, сделанные с помощью Sl4j.

Allure позволяет группировать сценарии по Epic/Feature/Story/Case. Это полезно, если у вас есть (должны быть) тестовая модель и матрица зависимости. И когда просматриваешь отчет, который сгруппирован так, как у вас модель тестовая составлена, то становится очень удобно, т.к. по упавшему тесту в отчете сразу видно, какой связанный функционал пострадал и потенциально стал нерабочим.

Требование к наличию модели и матрицы зависимости в сочетании с отчетами в Allure позволяют создавать базу для внедрения различных методик расчета метрик, т.к. все команды выгружают такие результаты.

Все результаты собираются в одном месте по проектам/командам и вместе дают ту самую целую картину здоровья ИТ-ландшафта. Причем, собираются также результаты тестов, которые написаны не на Tladianta.

Это уже не фреймворк Tladianta (он только генерирует данные), это уже процесс Tladianta.

Какие задачи решает:

• BDD стиль в написании сценариев.
• удобство в расследовании падений.
• единая отчетность, сбор метрик и легкое формирование Dashboards.
• Использование в Agile командах

Передача данных между шагами и сценариями.

Идеология cucumber настаивает на том, что каждый шаг сценария по своему поведению должен быть независимым и самодостаточным (атомарным). То же относится и к сценарию.

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

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

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

Кроме того, данный контекст можно закрепить за конкретным сценарием и сохранить его в базе данных. Опционально. Для этого есть отдельные методы, их можно использовать в Before/After-хуках в проекте.

По-умолчанию контекст сценария очищается перед каждым сценарием и не сохраняется в базу данных.

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

Какие задачи решает:

• удобство e2e тестирования;

Шаблонные проекты.

Это часть семейства инструментов Tladianta.

Мы сделали заготовки, шаблоны проектов, которые настроены на работу с каким-то одним плагином. Сделали в них структуру со всеми ключевыми пакетами и классами. Сделали настройку для фичи гостевой проект, для выгрузки отчета Allure.

Просто делай клон, пиши имя проекта и начинай писать тесты.

В проектах можно кастомизировать почти все, что может фреймворк:

• реализацию шагов
• механизм конфигурирования
• механизм поиска элемента страницы
• работу с рефлексией
• генераторы значений
• порядок инициализации контекста проекта
• можно использовать свои инструменты записи видео
• использовать не PageObject.

Какие задачи решает:

• легкий старт и удобство настройки;
• охват основных платформ разработки;
• возможность настройки под команду или под систему;

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

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

Мы сделали репортер в ALM и репортер в Jira.

Jira-reporter, например, создает задачу на реализацию новых шагов на автоматизатора в команде, а также задачу на расследование падения сборки со всеми ссылками и логами.

Tladianta-editor

Это плагин для среды разработки IntelliJ IDEA.

Его основное назначение повысить скорость и комфорт в разработке сценария.

Можно создать рабочий сценарий не выходя из файла .feature, при условии что использован шаблонный проект, конечно.
Он позволяет:

• выбрать шаг из доступной библиотеки шагов
• перейти из шага сразу в его step definition (это должно быть знакомо)
• позволяет создать заглушку step definition для нового шага (это тоже)
• выбрать страницу из списка в шаге установки текущей страницы
• а также создать новую страницу с элементами и блоками, не уходя из редактирования сценария
• провалиться в класс страницы, если уж так сильно нужно.
• набивать стрелочный путь до элемента в блоке, который в блоке и т.д.
• выбирать шаги гостевого проекта после переключения на его контекст
• выбирать страницы гостевого проекта после переключения на его контекст
• редактировать сценарий как дерево, добавляя и удаляя группировки шагов. Уровень вложенности любой
• и прочее.

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

Реализацию нового шага или специфичную реализацию существующего шага придется все-таки писать самостоятельно. Но для этого есть автоматизатор :-)

Заключение

Как видите, мы нарушили много канонических положений BDD. При этом мы сделали cucumber пригодным для использования в наших банковских реалиях. Получился такой cucumber по-росбанковски. Поэтому и Tladianta.

Не все идеи мы придумали сами. Многие из них мы почерпнули из трудов таких замечательных ребят как Константин Мальцев, Виктор Сидоченко, Алексей Лустин, Артем Ерошенко и других авторов open-source проектов.

Работа над фреймворком Tladianta не завершена. Мы его полируем и дополняем. Некоторые фичи еще не реализованы, о них, как и о представленных в статье, более подробно я расскажу в следующих статьях.