А как надо? Вместо моков выносить интерфейсы и создавать реализации исключительно ради тестов? Чтобы было прикольнее по проекту навигироваться?
Чтобы не сойти с ума от количества моков, которые описываются в отрыве от контракта. И да, для того, чтобы прикольно навигировать. Классический страх классов.
Чтобы не сойти с ума от количества моков, которые описываются в отрыве от контракта. И да, для того, чтобы прикольно навигировать. Классический страх классов.
Вот про это кстати было бы интересно послушать. Разве мокито позволяет делать что-то не по контракту? Или контрактом является что-то не входящее в сигнатуру методов?
Тыкать каждый раз найти использование проще, чем просто ткнуть на вызов метода и увидеть реализацию? Разумеется для случаев, где реализация планируется только одна в работающем коде.
Речь про большенство случаев, когда есть компонент из нескольких классов, каждый из которых хочется протестировать отдельно. Лежат они рядом, в соседних файлах. Понятно, что если надо разворачивать зависимости - интерфейсы нужны. Но у меня такого кода мало.
Джейк, конечно, не первый. Ребята из JB на форуме котлина, кажется, обмолвились, что тоже не мокают. Но много ли таких команд? Чет совсем экстрим и весь бойлерплейт руками.. хз, хз.
Вот про это кстати было бы интересно послушать. Разве мокито позволяет делать что-то не по контракту? Или контрактом является что-то не входящее в сигнатуру методов?
Не а том дело позволяет или нет, а в том, что не очевидно какой контракт использует мокито. На практике вещей у всех порядок в голове, когда реализован явный контракт в виде интерфейса.
Тыкать каждый раз найти использование проще, чем просто ткнуть на вызов метода и увидеть реализацию? Разумеется для случаев, где реализация планируется только одна в работающем коде.
Тыкать в наследников контракта проще чем тыкать в каждый метод в надежде увидеть его использование в конкретном тесте. Точка входа в контракт не размазана.
Не а том дело позволяет или нет, а в том, что не очевидно какой контракт использует мокито. На практике вещей у всех порядок в голове, когда реализован явный контракт в виде интерфейса.
Поясни пожалуйста, я не понял о каком контракте мы говорим. Мокито только изменяет выдаваемые результаты. Или тут опасение, что кто-то будет мокать другие методы, которые наш тестируемый класс не вызывает?
Опасений никаких, просто неявно изменять результаты без какого-либо контракта выглядит более не очевидно чем наличие явного контракта.
Чем сигнатура публичных методов отличается от сигнатуры экспортированных этих методов в интерфейс? Он же никакой другой информации не содержит. А изменяться всеравно будут только те результаты, которые мы вызываем в тестируемом обьекте. Ничего другого мокито изменять по сути то не умеет.
Джейк, конечно, не первый. Ребята из JB на форуме котлина, кажется, обмолвились, что тоже не мокают. Но много ли таких команд? Чет совсем экстрим и весь бойлерплейт руками.. хз, хз.
А что если я тебе скажу, что можно писать приложения на одних функциях и тестить без моков
У котлина действительно интересные тесты, нестандартный подход. Советую глянуть кому интересно, сорцы открыты. Интересно, написали ли они тулу, которая покрытие такими тестами измерять умеет -)
Нет, под ведро на котлине и даже в проде. Хотя на хаскеле проще, там это объяснять не надо
Можно в теории, или кто-то так действительно делает в проде и считает, что так писать и поддерживать проще, чем если не упарываться за чистоту функций?
Чем сигнатура публичных методов отличается от сигнатуры экспортированных этих методов в интерфейс? Он же никакой другой информации не содержит. А изменяться всеравно будут только те результаты, которые мы вызываем в тестируемом обьекте. Ничего другого мокито изменять по сути то не умеет.
Тем и отличается, что весь публичный контракт в интерфейсе и понять его наследников сверху намного проще.
Каких наследников? Вроде все началось с того, что мы ввели интерфейс только для тестов. Т.е. не было там наследников, а стал один. А публичный контракт класса IDE умеют показывать в Structure.