Всем привет) как часто вы в автотестах объединяте некоторые тесты

Question

Всем привет) как часто вы в автотестах объединяте некоторые тесты

в один?
К примеру у вас есть апи ендпоинты по каталогам из вашей бд. Они могут отличаться количеством ключей/значений, типом проверок.
Какой вариант лучше в данном случаи?
1. Написать хелпер/сервис/функцию которая будет делать запрос, получать ответ и в цикле проверять ключи/знаения
2. Вынескти вообще весь блок тестов (it) в функцию, в которой будет код из пункта один.

При этом каталогов может быть 200 штук. Стоит ли их запускать их генерируя it в массиве? Или лучше изолировать их в разные файлы и использовать хелпер/сервис/функцию?

#programming #qa #russian #software

0

02.06.2021

10 ответов

13 просмотров

Roman Rytikov Автор вопроса

Dmytro Slobodianiuk
лучше будет тот вариант, который следует принципу ...

Ну вот я тоже придерживаюсь такого принципа, но код на проекте ревьюят фронты и не могу им никак доказать, что их подход drycode в тестировании является избыточным и не всегда ведёт к качетсвенному тестированию. Есть у кого то есть аргументы за и против мне бы это очень помогло.

0

02.06.2021

Shoo

Логику запросов - переиспользовать (по максимуму до тех пор, пока это не ведет к переусложнению кода). Логику проверки ключей/значений - переиспользовать (по максимуму до тех пор, пока это не ведет к переусложнению кода. Тесты - разделять и делать независимыми.

0

02.06.2021

Roman Rytikov Автор вопроса

Shoo
Логику запросов - переиспользовать (по максимуму ...

Как понять что переусложнил? Это же я писал, я понимаю что там. А вот команда ручников, которую я учу... Вот им уже может быть сложно

0

02.06.2021

Shoo

Roman Rytikov
Как понять что переусложнил? Это же я писал, я пон...

Ну, более-менее традиционными способами измерения сложности кода является цикломатическая сложность, количество и глубина вложенности логических операторов и общий объём информации в коде (начиная от количества строк и заканчивая количеством сущностей и переменных, которыми оперирует функция/класс/модуль/сервис). Формально, для измерения всего этого добра есть отдельные метрики и инструменты, но обычно это видно даже визуально. Банальный пример, вы говорите что у вас есть Н ручек АПИ со схожей логикой. Предположим, вы написали универсальную функцию, отправляющую запрос на любую из них. В хорошем случае, вы просто компонуете входные параметры в нужном вам порядке и делаете вызов к апи. Код остаётся предельно простым - тут подставили имя эндпоинта, тут параметры. В плохом случае логика того, как делать запрос для этих ручек отличается, и ваша универсальная функция представляет собой набор if/else/switch statements, внутри каждого из которых вы описываете что делать в каком случае. В таком случае становится понятно, что дублирующейся логики между этими запросами не так уж и много, и их проще разделить на разные функции, каждая из которых будет отвечать за свой кусок логики.

0

02.06.2021

Jain Shemetova

Мне кажется тут можно использовать тот же принцип что и в классической разработке (ООП том же). А именно максимально переиспользовать логику и не дублировать Я конечно весьма обще написала но я думаю мысль вы поняли)

0

02.06.2021

Roman Rytikov Автор вопроса

Jain Shemetova
Мне кажется тут можно использовать тот же принцип ...

Ну так да) они и хотят ООП) проблема в том что написание и потом поддержка этих тестов кем то другим сильно усложняется

0

02.06.2021

Jain Shemetova

Roman Rytikov
Ну так да) они и хотят ООП) проблема в том что нап...

Трачу много сейчас времени не на сами тесты а на архитектуру и на поддержание в будущем. Но время на архитектуру как правило окупается в будущем. Ну и стараюсь писать код максимально просто (без усложнения там где не требуется). Это в будущем очень спасет

0

02.06.2021

Shoo

Jain Shemetova
Мне кажется тут можно использовать тот же принцип ...

Ну, как вам сказать. Одним из принципов того же ООП является Single Responsibility. Поэтому там тоже тонкая грань между «переиспользовать код» и «не плодить god objects ради недублирующегося кода».

0

02.06.2021

Jain Shemetova

Shoo
Ну, как вам сказать. Одним из принципов того же О...

Это безусловно) есть целая книга этому посвященная

0

02.06.2021

Dmytro Slobodianiuk · Accepted Answer

Dmytro Slobodianiuk

лучше будет тот вариант, который следует принципу один тест - один ассерт, может даже soft

0

02.06.2021

207 похожих чатов

Всем привет) как часто вы в автотестах объединяте некоторые тесты

10 ответов

Похожие вопросы