Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Единственный запуск setUp и tearDown для тестовых методов разных модулей


(Salasar) #1

Коллеги, добрый день.
Пытаюсь с помощью python 2.7 + unittest + webdriver автоматизировать тестирование у себя на проекте.
Организовал структуру автотестов в виде: один тестовый метод - один модуль (это мне кажется удобным, в силу специфики проекта). Test suit организовал в другом модуле. Но есть одна загвоздка - методы setUpClass и tearDownClass вызываются не в начале и конце сьюта, как бы мне хотелось, а перед каждым тестом (что, я понимаю, логично, на то они и методы класса). Есть ли вариант запуска методов подготовки тестового окружения в начале и конце тестового набора? Возможно, unittest не пригоден для такой архитектуры тестов?


(Александр Таранков) #2

Напрашивается вопрос: зачем делать такую структуру тестов?


(Salasar) #3

Один тест содержит около 20 вызовов методов работающих с элементами страницы. Будет около 15 тестов, каждый на свой функционал сайта. Мне показалось лучшим вариантом для дальнейшей поддержки и развития каждый тест выносить в отдельный модуль, а модуль хранить в отдельной “ветке” (пакете модулей) подобно схеме навигации на сайте. Просто, если намешать все тесты с их методами в один класс получится достаточно большая “простыня”. Если это технологически неправильно, прошу меня поправить.


(Александр Таранков) #4

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

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

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

Один тест содержит около 20 вызовов методов работающих с элементами страницы

Почитай про паттерн PageObject, посмотри видеоуроки для новичков по автоматизации. Будет хорошо, если “под рукой” есть разработчики, которые смогут отвечать на возникающие вопросы. Со временем научишься писать правильно.

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