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

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

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

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

10 ответов

15 просмотров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсуждают сегодня

30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
Как передать управляющий символ в открытую через CreateProcess консоль? Собсна, есть процедура: procedure TRedirectThread.WriteData(Data: OEMString); var Written: Cardinal;...
Serjone
6
в JclConsole объявлено так: function CtrlHandler(CtrlType: DWORD): BOOL; stdcall; - где ваше объявление с stdcall? у вас на картинке нет stdcall
Karagy
8
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
~ 2m21s  nix shell github:nixos/nixpkgs#stack ~  stack ghc -- --version error: … while calling the 'derivationStrict' builtin at /builtin/derivation.nix:...
Rebuild your mind.
6
Карта сайта