Size: a a a

Android Dev Подкаст

2019 March 08

IB

Ivan Balaksha in Android Dev Подкаст
Олег Осипенко
а PowerMock - это код смелище
Вместе с mock-maker-inline
источник

D

Dmitry in Android Dev Подкаст
Ivan Balaksha
Так это же норм, mockito - код смел
А как надо?
Вместо моков выносить интерфейсы и создавать реализации исключительно ради тестов? Чтобы было прикольнее по проекту навигироваться?
источник

IB

Ivan Balaksha in Android Dev Подкаст
Dmitry
А как надо?
Вместо моков выносить интерфейсы и создавать реализации исключительно ради тестов? Чтобы было прикольнее по проекту навигироваться?
создать по одному фейку не такая большая проблема. Какая разница в плане навигации, если на больших проектах она в принципе не работает ?
источник

AE

Alexander Efremenkov in Android Dev Подкаст
Dmitry
А как надо?
Вместо моков выносить интерфейсы и создавать реализации исключительно ради тестов? Чтобы было прикольнее по проекту навигироваться?
Чтобы не сойти с ума от количества моков, которые описываются в отрыве от контракта. И да, для того, чтобы прикольно навигировать. Классический страх классов.
источник

D

Dmitry in Android Dev Подкаст
Alexander Efremenkov
Чтобы не сойти с ума от количества моков, которые описываются в отрыве от контракта. И да, для того, чтобы прикольно навигировать. Классический страх классов.
Вот про это кстати было бы интересно послушать. Разве мокито позволяет делать что-то не по контракту? Или контрактом является что-то не входящее в сигнатуру методов?
источник

D

Dmitry in Android Dev Подкаст
Тыкать каждый раз найти использование проще, чем просто ткнуть на вызов метода и увидеть реализацию?
Разумеется для случаев, где реализация планируется только одна в работающем коде.
источник

D

Dmitry in Android Dev Подкаст
Речь про большенство случаев, когда есть компонент из нескольких классов, каждый из которых хочется протестировать отдельно. Лежат они рядом, в соседних файлах.
Понятно, что если надо разворачивать зависимости - интерфейсы нужны. Но у меня такого кода мало.
источник

K

Kopusha in Android Dev Подкаст
Джейк, конечно, не первый. Ребята из JB на форуме котлина, кажется, обмолвились, что тоже не мокают. Но много ли таких команд? Чет совсем экстрим и весь бойлерплейт руками.. хз, хз.
источник

AE

Alexander Efremenkov in Android Dev Подкаст
Dmitry
Вот про это кстати было бы интересно послушать. Разве мокито позволяет делать что-то не по контракту? Или контрактом является что-то не входящее в сигнатуру методов?
Не а том дело позволяет или нет, а в том, что не очевидно какой контракт использует мокито. На практике вещей у всех порядок в голове, когда реализован явный контракт в виде интерфейса.
источник

AE

Alexander Efremenkov in Android Dev Подкаст
Dmitry
Тыкать каждый раз найти использование проще, чем просто ткнуть на вызов метода и увидеть реализацию?
Разумеется для случаев, где реализация планируется только одна в работающем коде.
Тыкать в наследников контракта проще чем тыкать в каждый метод в надежде увидеть его использование в конкретном тесте. Точка входа в контракт не размазана.
источник

D

Dmitry in Android Dev Подкаст
Alexander Efremenkov
Не а том дело позволяет или нет, а в том, что не очевидно какой контракт использует мокито. На практике вещей у всех порядок в голове, когда реализован явный контракт в виде интерфейса.
Поясни пожалуйста, я не понял о каком контракте мы говорим.
Мокито только изменяет выдаваемые результаты. Или тут опасение, что кто-то будет мокать другие методы, которые наш тестируемый класс не вызывает?
источник

AE

Alexander Efremenkov in Android Dev Подкаст
Опасений никаких, просто неявно изменять результаты без какого-либо контракта выглядит более не очевидно чем наличие явного контракта.
источник
2019 March 09

D

Dmitry in Android Dev Подкаст
Alexander Efremenkov
Опасений никаких, просто неявно изменять результаты без какого-либо контракта выглядит более не очевидно чем наличие явного контракта.
Чем сигнатура публичных методов отличается от сигнатуры экспортированных этих методов в интерфейс?
Он же никакой другой информации не содержит. А изменяться всеравно будут только те результаты, которые мы вызываем в тестируемом обьекте. Ничего другого мокито изменять по сути то не умеет.
источник

I

Igor in Android Dev Подкаст
Kopusha
Джейк, конечно, не первый. Ребята из JB на форуме котлина, кажется, обмолвились, что тоже не мокают. Но много ли таких команд? Чет совсем экстрим и весь бойлерплейт руками.. хз, хз.
А что если я тебе скажу, что можно писать приложения на одних функциях и тестить без моков
источник

K

Kopusha in Android Dev Подкаст
на хаскеле, для курсовой в универе?
источник

D

Dmitry in Android Dev Подкаст
У котлина действительно интересные тесты, нестандартный подход. Советую глянуть кому интересно, сорцы открыты.
Интересно, написали ли они тулу, которая покрытие такими тестами измерять умеет -)
источник

I

Igor in Android Dev Подкаст
Kopusha
на хаскеле, для курсовой в универе?
Нет, под ведро на котлине и даже в проде. Хотя на хаскеле проще, там это объяснять не надо
источник

D

Dmitry in Android Dev Подкаст
Igor
Нет, под ведро на котлине и даже в проде. Хотя на хаскеле проще, там это объяснять не надо
Можно в теории, или кто-то так действительно делает в проде и считает, что так писать и поддерживать проще, чем если не упарываться за чистоту функций?
источник

AE

Alexander Efremenkov in Android Dev Подкаст
Dmitry
Чем сигнатура публичных методов отличается от сигнатуры экспортированных этих методов в интерфейс?
Он же никакой другой информации не содержит. А изменяться всеравно будут только те результаты, которые мы вызываем в тестируемом обьекте. Ничего другого мокито изменять по сути то не умеет.
Тем и отличается, что весь публичный контракт в интерфейсе и понять его наследников сверху намного проще.
источник

K

Kopusha in Android Dev Подкаст
Каких наследников? Вроде все началось с того, что мы ввели интерфейс только для тестов. Т.е. не было там наследников, а стал один. А публичный контракт класса IDE умеют показывать в Structure.
источник