Email or username:

Password:

Forgot your password?
Tech's posts Post Back to profile
Top-level
vCarabis

@tech
Спецификации должны чётко описывать на каком наборе входных параметров какой результат ожидается. Этого вполне достаточно чтобы написать тест. Что происходит там внутри не должно влиять на это.

Другой вопрос что далеко не все функции имеет смысл тестировать. Например функции с тривиальной логикой. Ну и как сказали выше, если писать код с прицелом на тесты, моки и т.д., работать это все будет не очень хорошо, да и поддержка такого кода может быть слишком трудоемка.
@devadideva

7 Apr 2023 at 16:21 | Wall-to-wall | Open on mastodon.social
4 comments
devadideva

@vCarabis@mastodon.social @tech@mastodon.ml Так в том то и дело, что поведение функции не всегда однозначно определяется входными параметрами! Но это уже было обсуждено. Спасибо за отклик!

7 Apr 2023 at 16:24 | Open on mk.phreedom.club
vCarabis

@devadideva
Возможно тогда стоит пересмотреть дизайн самой функции и все что влияет на её поведение вынести за её пределы и сделать входными параметрами. Если таких параметров много будет, то я бы задумался о декомпозиции такой функции.
@tech

7 Apr 2023 at 17:09 | Open on mastodon.social
devadideva

@vCarabis@mastodon.social @tech@mastodon.ml В общем то я с Вами согласен (привет тем, кто написал getopt и иже с ним!), но не во всех случаях это возможно: например функция socket(); структура сокета аллоцируется системой, а в ручки попадает только дескриптор. Вы бы как переписали эту системную функцию, а? Отдавали бы структуру сокета пользователю? Это неудачное решение.

7 Apr 2023 at 17:16 | Open on mk.phreedom.club
vCarabis

@devadideva
Если бы мне надо было проверить правильность заполнения структуры функцией socket(), я бы не писал тест для этой функции совсем :)

Я бы сделал логику этой публичной функции тривиальной, например линейная серия вызовов внутренних функций, которые не доступны конечному пользователю socket(), и вот их бы уже тестировал.

Эти функции уже можно написать однозначно вычисляющими результат. Главное не сильно увлечься этим делом и не загонять каждую строку кода в отдельную функцию
@tech

@devadideva
Если бы мне надо было проверить правильность заполнения структуры функцией socket(), я бы не писал тест для этой функции совсем :)

Я бы сделал логику этой публичной функции тривиальной, например линейная серия вызовов внутренних функций, которые не доступны конечному пользователю socket(), и вот их бы уже тестировал.

7 Apr 2023 at 17:37 | Open on mastodon.social
Go Up