Ребят помогите плз, как тестировать подобные методы? bookPreviewEntities - приватное

поле,и я не могу его задать через конструктор. Поэтому в тестах оно всгеда null и логика не тестируется.

Я вижу это так: штука приватная, а замокать ее надо. Значит передай ее в конструктор?

Да, можно так.Но тогда мне придётся менять код конструктора,и зачем-то передавать в презентер данные,которыми активити не распологает

Если менять код-я мог бы это поле и пабликом сделать на время теста, но разве мы должны подгонять код под тесты?

Нет, не должны. Но передавать зависимости в конструктор - это как раз норма. Особенно если мокать их придётся

А что оно вообще такое, это поле?

данные из более глубоких слоёв, которые мне нужны чтобы сделать список айтемов и послать в адаптер

А много ты над ними действий в презенторе делаешь?

вообще я думал, так и поступлю. Примерны с передачей репозитория и прочего в конструктор казались очевидными, а вот о том чтобы вообще всёё передавать через конструктор я не думал.

в основном конвертирую даблы в строки для отображения во view и т.д,а что ?

Я посмотрел еще на тот скриншот. Слушай, ты там за viewState дергаешь, так? Оставляй все как есть и просто введи проверку, что нет исключений и за нужный метод viewState ты дернул

та не, думал, что если там маппинг более-менее, то можно вынести в отдельный класс и отдельно тестировать

да но просто метод addBook вызывается не только из этой паблик функции. И следовательно я каждый раз должен писать один и тот же код,тестирующий вызовы view?

Просто я видел точку зрения,что мы содержание приват методов вообще смотреть не должны, чтобы не зависеть от реализации

Так а как по тому скрину понять, что метод приватный?)

по скрину никак)) но я в сообщении к скрину это написал

Я про onBookDismiss. Он приватный?

не, он паблик

ну вот с ним можно попробовать вариант, что я предложил

а всё,сорри,я подумал ты про второй скрин говорить начал. С первым скрином вроде всё понятно.Правда вопрос - получается по хорошему, у нас вообще не должно быть private полей,которые мы не задаём через конструктор? То есть в котллине у на всё будет а-ля class Foo(private val field1, private val field2..)?

Почему, нет. Всякую логику (ссылки на репы, интеракторы/юзкейсы) будешь через конструктор передавать - чтобы заменять их поведение на тестах. А какие-то там внутренние списки или еще что будут приватными. Я вот задумался, как это с MVP провернуть. Потому что на MVMM у тебя ViewModel меняет стейт обозреваемых контейнеров - ты просто слушаешь изменения стейта в тестах и сверяешь с желаемым. Тут бы я смотрел вызова методов viewState и сравнивал с желаемыми параметрами. Типа, тебе надо вход-выход для тестов сопостовлять в любом случае, просто найди свой 'return' и смотри, что ты там получишь

так подожди, если у меня будет хоть 1 внутренняя приватная переменная, я не смогу протестить метод который к ней обращается. И ведь в данном случае у меня и есть внутренний список,который ты предлагаешь через конструктор передавать.

Нет, я не знал, что это список обычный, так что забыли про эту идею. Тебе не нужно каждый чих тестить, я считаю. Смотришь ты на этот метод, не зная реализации, и что ждешь? Что он изменит состояние view. И через какой метод view он это сделает, верно?

да,я понимаю.Но проблема в том,что если создать объект презентера для теста, там этот список будет инициализирован null. Соответственно если посмотреть 1 скрин, можно увидеть,что ни одна функция не будет вызвана.

Тогда тут косяк именно что в самом классе. У тебя после работы конструктора должен быть на руках инстанс, полностью готовый к работе. В твоем случае, есть null и нужен, как я понял, вызов какого-то метода, чтобы это поле перестало быть null и весь класс стал юзабельным

Создавай список при инициализации класса, все равно он у тебя мутабельный

хм, ок, это решит данную проблему. А насчёт мелких случаев обращения к приватным полям класса, лучше не запариваться или же вызывать всю цепочку методов, чтобы сунуть туда нужное значение?

Прочитай сообщение над моим прошлым. Там человек простыми слоавми за это дело поясняет

Не понял пока

ну типо если пользователь открывал какую-то книгу,я сохраняю её индекс в приватном поле, и в onRestart делаю некоторые действия. Если просто запустить onRestart в тесте, никакая логика не отработает, потому что не было открыто ещё ни одной книги.

Так и в жизни так же - никакая логика не, если пользователь не открыл книгу

но ведь меня ещё интересует, корректна ли логика внутри этой проверки. Как написать тест для случая, когда какая-то книга была открыта.

Проведи "подготовку" объекта - дерни метод "книга открыта"

вот я про это и спрашивал ранее. Поулчается чтобы достичь нужного состояния объекта для теста, нужно повызывать другие паблик функции и проставить условия для функций у моков по необходимости.

Да

Да. Имхо, не стоит завязывать тест на внутреннюю реализацию класса. У тебя есть класс - как черный ящик с публичными методами для взаимодействия. Дергаешь эти методы в разном порядке, подаёшь на вход разные данные и смотришь что получилось на выходе.

Ух,да теперь вроде всё понятно, кроме предыдущего вопроса. Чем 3 приватных поля со скрина выше отличаются от зависимостей? Ведь я не могу передать им значение через конструктор и потому замокать

Ну вообще можешь и передать через конструктор если надо замокать)

Просто для тестов это кажется мега удобно, минимум кода, но с точки зрения сути класса, странно пихать в конструктор такие поля

кстати а если серьёзно, насчёт переноса приватных полей в конструктор на kotlin. В плане использования в коде разницы ведь никакой, точно так же инициализируешь поле дефолтным значениемю.Зато мокать можешь. Такой подход юзают вообще?