Рассмотрим файловую структуру тестового проекта, который в последствии будет запускаться в CI.
В корневой папке 6 разделов: api, generators, mysql, ui, tests, mock.
Помимо разделов там также находятся restructions.py, urls.py, start_test.sh, pytest.ini.
Fixtures — это функции, выполняемые pytest до, а иногда и после фактических тестовых функций. Код в фикстуре может делать все, что необходимо для начала или окончания тестирования. К примеру, можно их использовать, чтобы получить набор данных для тестирования или получить систему в известном состоянии перед запуском теста. Fixtures также используются для получения данных сразу для нескольких тестов. В разрабатываемом решении они всегда хранятся отдельно в файле fixtures.py и при необходимости совместного использования подключаются к файлу conftest.py Conftest.py – это файл, который pytest считывает в первую очередь в зависимости от иерархии каталогов, в котором он находится. В данном файле обычно хранятся настройки, предназначенные для тех тестов, в папке с которыми он находится. Если же необходима настройка сразу для нескольких подкаталогов, то conftest.py должен лежать на уровне с данными подкаталогами. Всё необходимое для разработки api-тестов хранится в директории api, это:
- base.py. Необходим для того, чтобы в дальнейшем вынести базовый функционал клиента API и наследоваться от него при разработке других api клиентов.
- client.py содержит клиент для вызова api тестируемого приложения.
- conftest.py содержит все настройки и подключенные фикструры.
- Error_classes.py содержит классы с разными видами ошибок, вызываемые при исключениях.
- fixtures.py содержит фикстуры, необходимые для разработки apiтестов. В директории generators находятся генераторы данных. Каждый из генераторов будет создавать тестовые данные определённого типа:
- api_json.py генерирует данные для api-тестов;
- email_data.py хранит генератор email адресов разных типов;
- registration_data.py хранит генератор данных, необходимых для регистрации;
- builder_base.py хранит базовый класс генератора, в котором определён основной функционал, необходимый для всех генераторов. В директории mysql находится всё, что необходимо для работы с базой данных:
- client.py содержит всё необходимое для подключения, настройки и создания базы данных и сессий.
- models.py содержит ORM модели таблиц базы данных.
- MysqlBuilder.py содержит готовые запросы для работы с базой данных.
- conftest.py содержит настройки и фикстуры, необходимые для работы с БД.
- В папке ui хранятся всё необходимое для ui-тестов, а именно:
- locators – директория с локаторами для нахождения ui объектов, созданных с разбиением на тестируемые страницы.
- pages – директория с функциями, разбитыми на страницы с помощью паттерна PageObject (каждый файл будет хранить функциональность необходимую только для работы с определённой страницей веб-приложения).
- input_data.py содержит вынесенные из тестов громоздкие входные параметры для тестов, чтобы сохранять хорошую читаемость файлов с тестами.
- base.py хранит всю базовую вспомогательную функциональность и часть настроек для ui-тестов.
- fixtures.py содержит фикстуры, необходимые для разработки uiтестов.
- В директории tests хранятся тесты как api, так и ui:
- api – директория с api-тестами, содержащая в себе файлы test_api.py и conftest.py с настройками и фикстурами именно для api тестов.
- ui – директорией с ui-тестами, содержащая в себе файлы test_ui.py и conftest.py с настройками и фикстурами для ui-тестов.
- сonftest.py содержит настройки и фикстуры, необходимые для всех типов тестов. Остаётся описать файлы, лежащие в корневой папке с тестовым проектом:
- restructions.py – переменные со значениями ограничений полей на UI и ограничений для значений, передаваемых в API.
- Urlis.py – url-адреса всех страниц веб-приложения.
- pytest.ini – основной файл конфигурации Pytest, который позволяет
изменить поведение настроенного по умолчанию тестового проекта.
*start_test.sh – скрипт на bash, который необходим для запуска тестового
проекта в CI.
Помимо самого тестового проекта, в разрабатываемом решении будут
директории для конфигурации и поддержки тестового окружения.
Файловая структура содержит пять основных директорий:
-
test_project – тестовый проект, в котором содержатся все рассматриваемые ранее файлы для организации тестирования.
-
config_tests – содержит всё необходимое для настройки тестового проекта: dockerfile, описывающий логику развёртки тестового проекта и requirements.txt – список зависимостей, которые необходимы для работы тестового проекта.
-
myapp_config – в данной директории находится всё нужное для запуска тестируемого приложения, а именно: app_config.txt – файл, из которого приложение при запуске берёт все необходимые параметры, директория database, которая содержит dockerfile для развёртки БД и init_db.sql – скрипт, необходимый базе данных для инициализации, и директория nginx, в которой хранится конфигурация для nginx-сервера, выступающего прокси-сервером для работы внутри созданной в Docker сети.
-
В Alluredir лежат данные, которые сохраняет allure, они используются в дальнейшем для генерации отчётов о проведённом тестировании.
-
selenoid– в данной директории хранится конфигурационный файл для настройки selenoid: файл с конфигурацией браузеров и их версий, которые будут использоваться при тестировании. Рассмотрим архитектуру разрабатываемого решения на рис. 7, на нём также пронумерована последовательность запуска компонентов:
В первую очередь запускается база данных MySQL, так как данный компонент необходим как для работы тестируемого приложения, так и для работы тестов. Сразу за базой данных запускаются компоненты selenoid: сам selenoid, который будет использоваться для поднятия нод и организации функционирования драйверов; selenoid-ui, который будут давать возможность контролировать процесс тестирования в нодах, и образы драйверов браузеров selenoid, из которых будут создаваться ноды. Далее - тестируемое приложение. Так как внутри docker напрямую к нему обращаться не получится, необходимо сразу после него запустить прокси-сервер nginx, с помощью которого с приложением можно будет взаимодействовать, в том числе и драйверам, поднятым с помощью selenoid. Затем запускается mock-server, необходимый для полноценной работы приложения. После запуска всего необходимого стартует тестовый проект, в котором UI-тесты выполняются в selenoid, а API - тесты просто в тестовой среде. В процессе тестирования создаются тестовые артефакты, необходимые в дальнейшем для создания allure отчёта о проведённом тестировании. В самом конце запускается в CI allure и генерирует отчёт по имеющимся тестовым артефактам.