Unit тестирование в Android c Clean architecture 

СОДЕРЖАНИЕ: 00:00:00 - введение 00:00:39 - Clean architecture Android 00:01:40 - кратко, что такое Unit тестирование Android 00:02:25 - подключаем библиотеки JUnit и Mockito 00:03:26 - пишем тест на JUnit 5 00:14:46 - используем библиотеку Mockito

Единственный человек во всем ютубе, кто дает такую актуальную информацию. Спасибо вам

Спасибо, очень подробно! Кстати, что бы не создавать самому пакеты, можно нажать ctrl+shift+T и студия сама создаст класс с названием исходного класса+test с тем же пакетом в папке test

Спасибо, понятно, после ваших уроков статьи по этим темам читаются легче.

Спасибо, очень полезная тема!!

спасибо, сделайте еще пожалуйста на эту тему видео. Объясняете доступно но хочется больше примеров и по сложнее задачи

Как всегда все на высшем уровне, спасибо вам!

Спасибо, все очень понятно объясняете!

Спасибо за видео. Понравился стиль объяснения, спокойный рассказ с примерами без лишней воды - приятно слушать такое. Я конечно понимаю, что все упрощено для новичков, но некоторые моменты хотелось бы уточнить, т.к. где-то можно чуть улучшить, а где-то из-за упрощения даются немного вредные советы, которые сказываются потом. 1. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : вообще вначале, когда проект почти пустой и все элементарно, то классы с тестами могут лежать в точно таких же пакетах и называться по имени класса. Но чем дальше, тем все больше тесты должны быть структурированы иначе, чем основной код. У них будет единый фасад как точка входа, но вовсе не обязательно, что на каждый класс вообще будет ровно симметричный класс с тестами. Тесты должны быть не чувствительными к изменению структуры основного кода, а это означает, что если вдруг из того же UseCase мы захотим вынести что-то в отдельный класс или сделать изменение, которое не меняет поведение программы, то тесты при этом должны практически не меняться и на новый выделенный класс не создаются новые тесты, ведь поведение уже будет протестировано через внешний. Если соблюдать это правило про класс и симметричный тест класс к нему под тем же именем и расположением, то мы создаем лишнюю связанность, которая будет мешать при дальнейших изменениях кода. 2. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : еще хорошо бы показать, раз код в IDE, что тесты создавать проще не вручную, а через хоткеи: Alt+Enter (если windows) и там через диалог дальше. А создавать тесты в том же пакете и переключаться между основным кодом и тестами можно по Ctrl+Shift+T. Вот тут можно посмотреть справку: www.jetbrains.com/help/idea/create-tests.html. 3. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : стандартным Assertions лучше предпочесть AssertJ и ему подобные с более выразительным синтаксисом, где вместо assertEquals(a, b), в котором новички долго путаются где “ожидаемое”, а где “реальное” на каком месте, - там будет assertThat(2+2).isEqual(4). 4. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : вообще-то, названия тестов как предложения с пробелами в котлине работают и для junit4, тут никакой разницы. “shouldReturnCorrectData” - совсем слабое название и второй вариант заметно лучше. И хотя “should” достаточно распространенная практика именования, но следовать ей не стоит: это лишнее слово в каждом тесте, притом еще и лексически означающее, что “тут следовало бы вернуть (но не обязательно)”, а мы хотим, чтоб поведение было строгим точным требованием без “желательно”. 5. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : а вот это неправильный и вредный совет. Как раз любым mock библиотекам лучше предпочитать свои тестовые утилиты с настоящими и полноценными методами, а где можно, то и реальные классы. Для этого нужно аккуратно продумать куда положить такой TestRepository, чтоб можно было переиспользовать в других тестах (т.е. не тут в этом же файле). Для этого кстати нельзя просто так забивать имена внутри (first и last name), а придется передавать данные параметрами. Это делается очень просто и потом легко менять в одном месте раз и для всех тестов. А вот с моками если что меняется, то нужно обновить каждый тест в отдельности. Настройка каждого мока - кроме того, что это лишний код - так это и каждый раз излишняя привязка к тому, как тест ожидает какой метод вызовется в основном коде и как он себя ведет. А это означает, что тест знает детали имплементации, чего он знать не должен. И именно это потом не позволяет менять основной код без тонны изменений в тестах. 6. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : mockito был стандартом в java. С котлином он изначально плохо работал. Зато упомянутый mockk и советую использовать вместо mockito - он создавался сразу для котлина с его синтаксическими возможностями, не требует второй вспомогательной библиотеки, более мощный (может при необходимости и object, и enum, и конструкторы чужих классов мокать). 7. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iGqVm0atAMQ.html : вообще да, про это и вправду надо задумываться будет ли сравнение по ссылке или по equals тоже сработает. Но для теста самого это не должно быть важным, ведь поведение будет работать так или иначе. Даже технически именно сам testUserName, а не копию, метод и вернет. А если очень важно убедиться, что возвращенное значение equals подобному, то это отдельно можно протестировать. Есть в AssertJ и методы такие как assertThat(actual).isSameAs(expected) (или isNotSameAs).

Спасибо за видео!

Спасибо за ваш труд!

Спасибо! :)

Выглядит и вправду смешно но в реальных проектах я думаю пойму всю прелесть использование тестов спасибо

Спасибо за видео!) 14:27 я представил как в офис разработки на 3м этаже, в помещение с джунами заходит сеньер и говорит что тесты сломались, вся команда подрывается и выпрыгивает в окно 😂

Спасибо большое.

🔥🔥🔥

лучший!

Сотый лайк 👍

Спасибо, все очень понятно объясняете) Вопрос: будут ли видео с тестированием viewModel? В котором возвращается какой-нибудь sealed класс state: с loading, success или error? Очень сложная для моего понимания тема)

лучший

Дякую

Как вы поставили кавычки в методе: should return the same data ...

let's make course about Jetpack Compose!!

Как ставить эти одинарные кавычки под скосом на маке?

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

Что делать? Выдает ошибку Mockito cannot mock/spy because : - final class. Хотя класс не финал. Это в котлин.

Привет, я начинающий андроид разработчик и для меня этот канал как алмаз среди груды мусора) Посмотрев твои уроки начал переделывать свой пет-проект на клин, но столкнулся с проблемой( У меня в проекте есть работа с API(retrofit+moshi+okhttp), если я правильно понял то это относиться к "data" слою ? Короче говоря, мои модельки для работы с API лежат в слое "data", а также эти модели нужны для слоя "domain", так как там описан интерфейс репозитория, как мне достучаться до этих моделек если по правильному я не могу юзать модели "data" в "domain" ? Заранее спасибо за ответ !

Есть вопросы. Вот мы тестируем реализацию UseCase'а(интерактор) . 1. Почему этот интерактор, не наследуется от какого-то интерфейса интерактора? То есть каким образом мы будем тестировать viewmodel, подставляю туда фейковый интерактор? 2. Так же хотел спросить, нет ли какого-то либо механизма, который позволяет тестировать интерфейс этого самого интерактора, но, чтобы посредством di каким-то образом в тест inject-ить реализацию этого интерактора. То есть, мы один раз провайдим реализацию интерфейса, а он уже сам тестируется, т.к. в тесте тестировался интерфейс, а не его реализация.

Тимофей привет! Выдает ошибку, Expected :...cleanarchitecturelearnapp.domain.models.UserName@632ceb35 Actual :...cleanarchitecturelearnapp.domain.models.UserName@1c93f6e1 Все как у тебя в коде.