Size: a a a

testing_in_python

2021 September 30

BW

Black White in testing_in_python
Подскажите пжл, как избавиться от копипаста:
у меня в файле фикстур есть одинаковые фикстуры, которые отличаються только вызовом разных функций, я пытался провернуть трюк через lazy_fixture но не помогло, где можно что-то почитать по этому поводу?
источник

BS

BLVCK SONNET in testing_in_python
создать класс и одну фикстуру, которая отдаёт его инстанс
источник

OC

Oleg Chaplashkin in testing_in_python
Ребят, что-то вчера такой идеалогический вопрос подъехал в голову: на каком уровне абстракции вы пишите клиенты под сервис(-ы) API?

Я сейчас больше не про крудошлепство, а про серьезные сущности.

По сути, можно, наверное идти в 3 направления:
1. Пишем клиент, который абстрагирует ТОЛЬКО роутинг и отправку (т.е. мы отправляем по сути сырые данные и получаем HTTP Response), все остальное (логика сборки данных, парсинга ответа) - дело системы автоматизации

client.entity.create( { name: test, lname: test })


2. Пишем клиент, где абстрагируем уже уровни сущностей и вводим DTO: например, запрос принимает не SpecialDataClassRequest и возвращает уже не HTTP Response, а SpecialDataClassResponse
e: Entity = Entity(name="test", lname="test")
client.entity.create(e)


3. Пишем клиент, где абстрагируем уровень сборки сущностей: мы просто через какую-то фабрику/строитель(паттерны) накидываем, что то типа:
e = client.entity(). \
.set_name() \
.set_lname() \
.build() \

client.entity.create(e)


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

С другой стороны, у меня часто бывает, что клиенты "выплывают" наружу и им начинают пользоваться сначала коллеги, потому вообще как SDK в open source.

Есть идеи?
источник

А

Андрей in testing_in_python
*то чувство, когда твой тестовый клиент надежнее девовского? )
источник

EB

Evgenii B in testing_in_python
Никаких особо советов кроме «найдите, как вам удобнее будет поддерживать тесты» наверное у меня нет
источник

EB

Evgenii B in testing_in_python
Но наверное хорошо когда тестовый код и апи тест клиента имеет несколько интерфейсов : один имеет доменные методы и возможность низкоуровневых методов
источник

P

Philip in testing_in_python
В этих именах ничего непонятно. Что из себя представляют эти фикстуры? Зачем их передают в тесте в класс CounterpartyPageGeneral? Чтобы создать страницу? Так а разве сама фикстура уже не старница?
Где копипаста, которую убрать хочется?
источник

OC

Oleg Chaplashkin in testing_in_python
Думал об этом, но я не знаю как без копипасты корректно это реализовать

Через что подобное делается(стратегия?) или где можно посмотреть?
источник

BW

Black White in testing_in_python
на скрине в левой части 4 одинковых фикстуры(они заимствуют одну и туже логику от другой фикстуры get_counterparty_page), отличаются они только вызовом разных функций page.имя_функции (функции делают клик по пунктам меню, каждая по своему пункту)
Логика таковая, что у меня есть одинаковый функционал в разных вкладках меню и я при переходе в каждую вкладку(через фикстуру) запускаю одни и те же тесты
источник

P

Philip in testing_in_python
Тогда справа в тестах надо у фикстуры вызывать проверки, а не создавать ещё раз page.
check, msg = fixture.check_arrow….
источник

А

Алексей in testing_in_python
Вариант 1. Так как в тестировании часто нужно отправлять всякий шлак, который не понравится этим ДТО объектам. Дальше придется вставлять костылики-мутации в оные ДТО для поддержки таких негативных сценариев, и красивая структура валится. Так что клиент только для роутинга. Если это клиент для использования другими группами (ручниками и тп) - просто для них добавляете отдельный слой абстракции, где и содержатся ДТО
источник

OC

Oleg Chaplashkin in testing_in_python
Спасибо!

Сейчас схему накидал, получается такая иерархия:

BaseClient - клиент только для роутинга

Client(BaseClient) - доменный клиент с DTO, имеет слой DTO и слой парсеров (DTO -> JSON -> DTO) и использует методы базового клиента (он как раз и принимает JSON)
источник

JM

Jackie Moon in testing_in_python
Если уж пошли идеологические вопросы, в чем профит преобразования JSON в dto? Метод eq и intellisense?
источник

BW

Black White in testing_in_python
а нельзя изобрести что-то вроде параметризации, в которой я подставляю нужные мне функции в фикстуру, м?
источник

А

Алексей in testing_in_python
если грубо то да.
источник

VD

Vadim Dudin in testing_in_python
Ну и всякие доп плюшки, например в том же schematics  есть валидация из коробки
источник

А

Алексей in testing_in_python
Формально - проверяемые пичармом поля вместо мэйджик стрингов, которые могут отличаться, о чем ты узнаешь только при выполнении кода
источник

А

Алексей in testing_in_python
А оно тебе надо? Хэлперы сделай например, вариантов много
источник

JM

Jackie Moon in testing_in_python
Понял, я просто graphql тестирую сейчас и работаю чисто со словарями, потому как дто, мне кажется только усложняет процесс (именно респонсов).
источник

BW

Black White in testing_in_python
Я просто не знаю как лучше и исхожу из того что знаю, полагая что это сократит мои 4 фикстуры до 1. Так как у меня это не один такой кейс.
источник