D
Size: a a a
2020 October 02
DT
Ну вот пример. Интерфейс Кеша на вход. Делаете гет. Что будете тестировать ?
А почему клиентский код дергает кеш? легче же превратить его в еще одну зависимость. Тогда пропадает каплинг на кеше, не?
DT
условно
D
А почему клиентский код дергает кеш? легче же превратить его в еще одну зависимость. Тогда пропадает каплинг на кеше, не?
Какой клиентский ? Сервис лезет в кеш. А тот упал из-за перегруженной сети
DT
Особенно когда какой нибудь класс принимает пару зависимостей и активно из юзает. Задолбаешься мокать чтобы каждый кейс отработать :(
DT
вот изначальное сообщение
DT
активно их юзает вообще ни разу не смахивает на поведение "получил - передал"JB
Проекты где я начал наркоманить тестами не имели права падать.
Я полностью согласен
JB
Это это не отменяет TDD
DT
Правильно. Тестируя сервис нужно мокнуть кеш. И этим моком создать все возможные кейсы падения Кеша. Чтобы сервис адекватно реагировал
почему сервис зависит от кэша, а не от значения? почему сервису важно получать значение именно из кэша? какая необходимость у этого сервиса в этом факте?
JB
По той причине, что какого хера, вы ставите брейк-поиты, вместо того чтобы написать тест навсегда
D
почему сервис зависит от кэша, а не от значения? почему сервису важно получать значение именно из кэша? какая необходимость у этого сервиса в этом факте?
Потому что сервис решает откуда брать данные. Он не зависит от Кеша. Он зависит от интерфейса. А кеш его реализует
DT
Потому что сервис решает откуда брать данные. Он не зависит от Кеша. Он зависит от интерфейса. А кеш его реализует
SRP