MM
Заменить потом реализацию на интерфейс, если надо, дело 5 минут
Size: a a a
2019 December 31
EY
makes sense
EY
Файнал не обязывает интерфейсы клепать, если чо
не обязывают - да, но, как их мокать тогда в тестах?
MM
А что и зачем ты мокать собрался?) В этом и проьлема
K
мокай закусь в соус
K
И закусывай!
EY
unit tests, обычная практика)
MM
Не вижу ничего обычного, или необычного. И нахуй в юнитах моки, тоже не оч ясно
SP
Eugene Yurkevich
Я чего спрашиваю, просто ни разу не делал свой класс final😭
1. Какие плюсы final дает?
Не дает унаследовать класс - ок. Но, в чем реальный плюс? Дает понять что "у тебя не должно быть мысли наследовать этот класс"? Так-то следующим коммитом я могу снести final, если оно не в vendor.
2. как с phpunit тестировать классы зависящие от final класса? Я вижу следующие варианты:
- а. мокать интерфейс если final класс его имеет.
- b. Передавать весь сервис-контейнер в конструктор и в тесте мокать контейнер get(). - но, это хрень на мой вгзляд, нафига передавать весь контейнер если намного наглядней передать конкретные зависимости.
Так, все таки, как тестировать код зависящий от final класса? Или не должно быть такой ситуации когда код зависит от конкретного final класса, а должен зависеть только от интерфейса (пункт а)
1. Какие плюсы final дает?
Не дает унаследовать класс - ок. Но, в чем реальный плюс? Дает понять что "у тебя не должно быть мысли наследовать этот класс"? Так-то следующим коммитом я могу снести final, если оно не в vendor.
2. как с phpunit тестировать классы зависящие от final класса? Я вижу следующие варианты:
- а. мокать интерфейс если final класс его имеет.
- b. Передавать весь сервис-контейнер в конструктор и в тесте мокать контейнер get(). - но, это хрень на мой вгзляд, нафига передавать весь контейнер если намного наглядней передать конкретные зависимости.
Так, все таки, как тестировать код зависящий от final класса? Или не должно быть такой ситуации когда код зависит от конкретного final класса, а должен зависеть только от интерфейса (пункт а)
EY
Проверяем, что будет вызван такой-то метод такого-то сервиса. Сервис может и в базу лезть и ракету на луну посылать, поэтому мокаем.
SP
эта статья полностью отвечает на все твои вопросы
SP
> TL;DR: Make your classes always final, if they implement an interface, and no other public methods are defined
MM
Eugene Yurkevich
Проверяем, что будет вызван такой-то метод такого-то сервиса. Сервис может и в базу лезть и ракету на луну посылать, поэтому мокаем.
мб в этом и проблема?) а не в файналах
SP
мб в этом и проблема?) а не в файналах
в чем проблема с моками?
MM
в чем проблема с моками?
да нет в них особой проблемы
EY
в том-то и проблема что finаl класс посылающий ракету не мокается если у него нет интерфейса
SP
Eugene Yurkevich
Я чего спрашиваю, просто ни разу не делал свой класс final😭
1. Какие плюсы final дает?
Не дает унаследовать класс - ок. Но, в чем реальный плюс? Дает понять что "у тебя не должно быть мысли наследовать этот класс"? Так-то следующим коммитом я могу снести final, если оно не в vendor.
2. как с phpunit тестировать классы зависящие от final класса? Я вижу следующие варианты:
- а. мокать интерфейс если final класс его имеет.
- b. Передавать весь сервис-контейнер в конструктор и в тесте мокать контейнер get(). - но, это хрень на мой вгзляд, нафига передавать весь контейнер если намного наглядней передать конкретные зависимости.
Так, все таки, как тестировать код зависящий от final класса? Или не должно быть такой ситуации когда код зависит от конкретного final класса, а должен зависеть только от интерфейса (пункт а)
1. Какие плюсы final дает?
Не дает унаследовать класс - ок. Но, в чем реальный плюс? Дает понять что "у тебя не должно быть мысли наследовать этот класс"? Так-то следующим коммитом я могу снести final, если оно не в vendor.
2. как с phpunit тестировать классы зависящие от final класса? Я вижу следующие варианты:
- а. мокать интерфейс если final класс его имеет.
- b. Передавать весь сервис-контейнер в конструктор и в тесте мокать контейнер get(). - но, это хрень на мой вгзляд, нафига передавать весь контейнер если намного наглядней передать конкретные зависимости.
Так, все таки, как тестировать код зависящий от final класса? Или не должно быть такой ситуации когда код зависит от конкретного final класса, а должен зависеть только от интерфейса (пункт а)
1. запрет расширения через наследование, если ты этого не предполагаешь на этапе проектирования класса
2. final вешается там где есть интерфейс либо не подразумевается что это что-то надо мокать (например ты не будешь мокать DateTime класс и расширять можешь не давать по дефолту).
2. final вешается там где есть интерфейс либо не подразумевается что это что-то надо мокать (например ты не будешь мокать DateTime класс и расширять можешь не давать по дефолту).
MM
вопрос в использовании) у тебя юнит тест куда-то лазит, что-то делает, по пути ещё в базу пишет) и ты такой, а мокну-ка я его. Нет же проблем никаких
SP
вопрос в использовании) у тебя юнит тест куда-то лазит, что-то делает, по пути ещё в базу пишет) и ты такой, а мокну-ка я его. Нет же проблем никаких
честно - нихуя не понятно какую мысль ты пытаешься выразить