ты весь код в тесте дублируешь

может ты?)

я не дублирую реализацию в тестах

давай конкретнее что там дублируется

p.s. а потом расскажи как ты будешь тестить клиент к апишке с финансовой инфой, от которой ты никогда не можешь добиться стабильной работы, то оно отваливается по сети, то оно еще как чудит. Или ты никак не можешь задать прекондишен для твоей апишки.

то есть каст исключений и вся фигня. Трансформация статус кодов точнее в исключение

трансформации как правило за пределами этого метода будут, как и сериализация

как ты добьешься воспроизводимости?

трансформации как правило за пределами этого метода будут, как и сериализация

если у меня код просто проксирует вызовы дальше - да, я не буду это покрывать юнитами. Ну мол он тупо делигирует и сам ничего не делает.

но мне часто лень выделять отдельно трансформеры/гидраторы

ну так а че твоя апишка то делать будет?

ну так а че твоя апишка то делать будет?

ты хочешь ее потестить, а тебе ни прекондишен не выставить ни стабильной работы не дождаться

что будет тестировать такой тест? если в методе апишки всего 3 операции выполняется с одной обработкой исключения, и то это как вариант будет лог + переброс другого исключения

и при чем тут сеть к юнит тестам?

гайз, а шо если мы сделаем ламповый митапчик в ирпене-буче? ну там пиво, мяско, поговорить...

природа, все дела

и при чем тут сеть к юнит тестам?

ну у меня есть юнит который работает по сети. Работа с сетью излирована отдельной прослойкой которую мы мокаем и она уже протещена. Что не так?

при помощи мока я делаю воспроизводимые условия, что мол дернули мы а нам пришла какашка, и как мой мэппер это захэндлит

вот если у тебя if-ов в коде нет - тогда да, юнит тест тут не особо нужен

гайз, а шо если мы сделаем ламповый митапчик в ирпене-буче? ну там пиво, мяско, поговорить...

можно, я только не пьющий, но мясо едящий и очень сильно :D

хотя если вместо if-ов математика например - уже надо

ну у меня есть юнит который работает по сети. Работа с сетью излирована отдельной прослойкой которую мы мокаем и она уже протещена. Что не так?

этим же не контроллер будет заниматься, верно?

гайз, а шо если мы сделаем ламповый митапчик в ирпене-буче? ну там пиво, мяско, поговорить...

эх... мне далеко ехать)

этим же не контроллер будет заниматься, верно?

верно. Отдельный юнит же

или я тебя не понимаю

а еще как вариант этот юнит, который куда-то по сети ходит, используется не в 1м методе, а в десятке разных

а еще как вариант этот юнит, который куда-то по сети ходит, используется не в 1м методе, а в десятке разных

что есть "метод"

вот как ты будешь этот десяток методов тестить? ведь этот юнит будет отдельно протестирован

может "модуль"?

вот как ты будешь этот десяток методов тестить? ведь этот юнит будет отдельно протестирован

цель юнита - уменьшить количество вариантов поведения

упростить для остального мира все

соответственно этот юнит для других модулей я буду тупо мокать и смотреть как они реагируют на различные ситуации

get /users/{id} get /users post /users/ ... для каждого метода будет вызов у тебя

т.е у тебя будет 10 одинаковых тестов?

get /users/{id} get /users post /users/ ... для каждого метода будет вызов у тебя

ну допустим, и?

т.е у тебя будет 10 одинаковых тестов?

почему одинаковых?

ты как-то странно рассуждаешь

давай возьмем простой кейс: - get /users/{id}

какие кейсы нас интересуют для модуля, который будет по апишке ходить: - нам пришел невалидный респонс - нам пришла ошибка сервера - таймаут - все хорошо и надо замэпить на объект

что регламентирует контракт этого модуля

какие кейсы нас интересуют для модуля, который будет по апишке ходить: - нам пришел невалидный респонс - нам пришла ошибка сервера - таймаут - все хорошо и надо замэпить на объект

get /users все тоже самое, post/put/delete туда же

контракт: - если была ошибка сервера или таймаут - повтори запрос пару раз - если пришла ошибка 404 - кинуть исключение что нет такого юзера - если другие ошибки - кинуть "другая ошибка". - если все хорошо - замэпить на объект и вернуть.

это ты клиента описал

да, это контракт клиента к API. Требования точнее к реализации

мы немного о разных вещах говорим

с точки зрения пользователей этого "клиента" мы получаем следующее поведение: - оно либо вернет нам юзера - либо кинет исключение что нет такого юзера - либо кинет исключение что что-то пошло не так. Этот кейс в других тестах нас не особо интересует.

вот допустим тебе нужно сделать сервер для апихи, которая будет отдавать юзеров этих юзеров она будет брать из другой апихи, клиент которого ты вот как раз описал

вот допустим тебе нужно сделать сервер для апихи, которая будет отдавать юзеров этих юзеров она будет брать из другой апихи, клиент которого ты вот как раз описал

ну оно ж меняет поведение?

вот твой сервер это пачка методов, которые юзают активно клиента для другой апихи. логика у них примитивная

ну мол это не тупо прокся? ты ж для чего-то делаешь свою прослойку?

ну пусть добавляет обфускацию паролей

целью ставишь упростить работу с ней

ну пусть добавляет обфускацию паролей

это типа... ниочем

или я хз, граватар аватарки дергает

я непонимаю что ты от меня хочешь

чтобы ты мне обьяснил как ты видишь юнит тестирование такой тривиальной логики)

чтобы ты мне обьяснил как ты видишь юнит тестирование такой тривиальной логики)

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

а если есть хотя бы один if - то добро пожаловать в юнит тесты

ооокей, у тебя метод который дергает юзера из соседней апишки может вернуть нулл, мы на этот случай 404 эксепшен выплевываем. из-за этого нужно писать целый тест?

1 кейс - apiClient вернет обьект, на выходе мы должны получить этот же обьект 2 кейс - apiClient вернул нул, на выходе мы должны поймать эксепшен протестировал?

даже давай граватар добавим. после того как достали юзера у него берем эмейл и просим его аватарку у граватара, если не нашлась тогда вставляем дефолтную. аж 3 кейса теперь

> мы на этот случай 404 эксепшен выплевываем ты это типа в контроллерах делаешь что-ли?

> из-за этого нужно писать целый тест? твой клиент должен по таймауту повторять запрос 3 раза.

ну мол retry middleware какой

это клиент внутри там занимается

apiClient->find() внутри сам все делает

он возвращает тоьлко 2 варианта, обьект или нул

тогда что ты пишешь?

контроллер, который сделает эти 2 сраных вызова и вернет результат

ERROR: S client not available

я про тестирование именно гоэтого apiClient

ну с этим apiClient все понятно

контроллер, который сделает эти 2 сраных вызова и вернет результат

контроллер не покрываем юнит тестами

погодь)

а если у тебя apiCLient пришел как либа

тогда вообще тесты не нужны?

он же контроллер, он занимается только flow control, там нет if-ов (не должно быть)

тогда вообще тесты не нужны?

ну если у тебя только протещенная либа и контроллеры и больше ничего нет - то да

я привел кейс с условиями, проверка на нулы не считаются?

ну и контроллеры тонкие

я привел кейс с условиями, проверка на нулы не считаются?

я бы сделал просто отдельный сервис-адаптер который бы это хэндлил

и уже это покрывал бы тестами

в контролерах не должно быть if-ов

p.s. ну ты же понимаешь что я крайности описываю? в реальной жизни я не буду замарачиваться по такой фигне

ну давай так, вот у тебя сервис, который на входе получает айдиху, а на выходе должен вернуть либо юзера с аватаром, либо юзера с дефолтной аватарой, либо эксепшен если не найден

тут руками тестить быстрее чем тест писать

особенно когда у тебя вообще все поведение необходимое (ну почти все) хэндлится этим твоим протещенным apiClient

которое и так тебе упрощет поведение снаружи

ну вот сервис как я выше описал, достоен юнит теста или все еще можно забить?)

ну вот сервис как я выше описал, достоен юнит теста или все еще можно забить?)

вполне достоен

вопрос в реализации

вот. у нас выходит 3 кейса разных будут проверяться?

можно сделать так что тест будет выглядеть бесполезным

а можно сделать так что будет ок

и тест будет дублировать всю реализацию и делать верификацию кода?

как бы ты написал чтобы этот тест был полезным?

я бы сделал провайдер аватарок который бы юзал граватар и если ничего не найдено возвращал бы просто картинку

вот это тестил бы да

а не тестировал компилятор-интерпретатор

а далее све превращается в просто последовательность операций - тут нечего проверять. разве что интеграционный тест

я бы сделал провайдер аватарок который бы юзал граватар и если ничего не найдено возвращал бы просто картинку

а его бы тестировал?)

а его бы тестировал?)

да, почему нет то?