ЧАСТЬ 3. BaseCase Pattern
Сегодня поговорим про еще один паттерн, который я называю BaseCase Pattern.
Его можно использовать как самостоятельно, так и в прекрасной комбинации с паттерном, о котором я говорил в части 2.
https://t.me/AQA_Engineer/145
Суть его заключается в следующем:
Создается класс BaseCase. В нем мы можем инициализировать необходимые клиенты, писать общие фикстуры, которые могут переиспользоваться.
Главное, что необходимо сделать — это наследовать класс с тестами от базового тест-кейса (BaseCase). Все классы-наследники будут иметь доступ к методам и свойствам, описанным в родительском классе.
class BaseCase:
@pytest.fixture(scope="session")
def http_dm_api_account_service(self):
client = HTTPDmApiAccountFacade()
return client
class TestsPostV1Account(BaseCase):
@pytest.fixture(scope="session")
def my_client(self, http_dm_api_account_service):
"""
Фикстура приведена для примера показать, что можем использовать в тестах фикстуры из BaseCase
Тут можно добавить свою логику, например авторизацию и т.д.
"""
return http_dm_api_account_service
def test_post_v1_account(self, my_client) -> None:
my_client.account_api.post_v1_account_for_test()
def test_post_v1_account_base(self, http_dm_api_account_service) -> None:
http_dm_api_account_service.account_api.post_v1_account_for_test()
Плюсы:
1. Прост в применении
2. Удобное масштабирование, достаточно создать класс наследник для своего сьюта и реализовывать там вспомогательную логику.
3. Легко читается и поддерживается.
4. Можно использовать, как отдельно инкапсулируя вспомогательную логику внутри класса наследника, так и использовать в качестве фасада для удобного доступа к клиентам
Минусы:
1. Тоже может возникнуть дублирование кода, ситуация схожая с Handler Pattern, но в отличие от него, достаточно удобно сделать перенос в класс более высокого уровня.
Резюме, паттерн классный, я стараюсь его использовать вместе с Helper Pattern.
Пишите какие паттерны встречали вы, или может есть что добавить к текущему посту.
TG-сообщество | Обучение |Отзывы