и имплементации, а в классах-клиентах предоставление зависимостей от абстракции? Одно из преимуществ насколько я знаю это упрощение тестирования, но разве с этим не справляется мокито?
Если у тебя есть класс, зависящий от презентера - он в будущем может получить любую релизацию. Соответственно можно делать изменение поведения не затрагивая клиентский код. Например добавить какой-нибудь враппер, который часть методов делегирует, а часть методов как-то иначе обрабатывает
финальный класс ты не замокаешь никак в жабе классы по умолчанию открыты к наследованию, а вот в котлине нет, а делать все классы open как-то не охота
а я не по котлину, вопрос изначально в конфе по дарту спросил
ну сори, уточнений не было, мокито вспомнил, вот я и подумал)
В мокито уже давно можно мокать финальные классы, там через небольшой хак это работает но все же есть возможность
Я могу ошибаться, но необходимость мокать финальные классы говорит о том, что вместо интерфейсов поставляются конкретные зависимости, я думаю, что само это не есть хорошо
Это да но например, я не делаю интерфейс для interactor/useCase считаю это излишни, но тестировать то надо его. Так что с мокито все ок работает.
Не совсем понял. Тестировать его в смысле что презентер/вьюмодель, куда его поставляешь?
Ага, понял
Обсуждают сегодня