Как стать автором
Обновить

Фреймворки для тестирования: личный опыт и новые методы

Время на прочтение 12 мин
Количество просмотров 22K
Всего голосов 17: ↑16 и ↓1 +15
Комментарии 9

Комментарии 9

А зачем вам так много тестов? Вы для своих разработок это делаете или для кого-то?

Спасибо за вопрос. Совсем немного пишем для себя, решаем некоторые задачки по автоматизации, по мониторингу, в компании ООО "Хоппер ИТ". Основная масса, конечно, для Заказчиков. Применение автотестов для мониторинга - очень востребовано. У многих Заказчиков есть свои команды, которые пишут тесты, мы им помогаем, проводим аудит, показываем лучшие практики, но где-то мы с нуля организовываем автоматизированное тестирование.

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

Архитектура основана на принципе Page Object. Разработчик сначала описывает ключевые элементы страниц через специальные классы, а затем закидывает их в класс-страницу, где можно реализовать необходимые методы для работы со страницей.

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

Нет, я имел в виду схему распределения объектов/методов по папкам/пакетам для разных автотестов - веба, api, 2F и т.д. И как в тестах к ним обращаетесь - через импорт нужных методов в каждом тесте, через инстанс класса фреймворка в фикстуре pytest или как-то еще?

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

Пробовали. В планах на него перейти.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории