🤔 По мере усложнения приложения, в какой-то момент вам перестанет хватать «плоской» навигации «активити-фрагмент», и понадобится вкладывать фрагменты друг в друга. Как это правильно реализовать?

🫣 Конечно, вы можете временно скрыться за очередной стеной абстракций, используя navigation component, но я вас уверяю, что при отсутствии чёткого понимания fragment manager и его транзакций, вы придёте к бардаку и костылям. По крайней мере, у меня было так =)

У каждого фрагмента есть доступ к трём FragmentManager (fm):

1️⃣ activity.supportFragmentManager – fm, до которого мы можем достучаться через родительскую активити. Пока вы не используете вложенность фрагментов друг в друга, его вам будет хватать.

2️⃣ parentFragmentManager – fm родительского компонента. Если Ваш фрагмент был вложен в другой фрагмент, то это будет fm родительского фрагмента, а если фрагмент вложен напрямую в активити – то это будет тот самый fm активити из пункта 1.

3️⃣ childFragmentManager – это fm, предназначенный для создания дочерних фрагментов у этого фрагмента. Только используя этот менеджер, вы сможете делать вложенную иерархию фрагментов.

🚀 А теперь проверим, насколько вам это понятно =)

Человек я или пёс, вот в чём вопрос

Добрался я тут до одной из книг, которую мне в менторско-психологическом коммьюнити часто советовали:
«Не рычите на собаку».

Книга в основном о дрессировке животных, хотя многие из этих паттернов применимы и к людям.

Забавно осознавать, что в определённом разрезе и человек, и собака, и дельфин – в целом подчиняются одним и тем же заложенным шаблонам :)

Книга написана относительно легко, но идёт у меня довольно тяжело, как и любая профессиональная литература. Как я уже когда-то говорил – книги читать я не мастак. Но порой нужно.

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

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

Если по-простому, то подкрепление – это способ показать человеку, что он что-то делает правильно или неправильно. Именно "делает", а не "сделал". Не после результата, а в процессе.

Как в игре "горячо-холодно", очень наглядный пример. Представьте, что в этой игре вам будут просто говорить "правильно / неправильно", когда вы будете называть место, где предположительно находится предмет. И представьте, как долго такая игра продлится?

Вот "горячо" – это положительное подкрепление, а "холодно" – отрицательное.

Заметьте: вам не по щщам дали за неправильное место, а вовремя показали, что вы двигаетесь не в том направлении. В этом, кстати, разница отрицательного подкрепления и наказания.

Интересный факт: положительные подкрепления куда сильнее отрицательных. Да и пользоваться ими проще: куда понятнее и приятнее похвалить человека, чем дать ему леща (кто бы что там ни говорил).

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

А что у вас в обучении лучше работает? Ловили ли себя на сопротивлении, или на страхе перед наказанием, или на желании получить похвалу?

P.S.: этот пост писался в диком сопротивлении и переписывался несколько раз, потому что я весьма хреновый ученик. Я плохо воспринимаю критику, даже если сам её прошу, и сопротивляюсь до последнего, даже если уже не понимаю зачем.

Ставь лайк если понимаешь, о чём я =)

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

Сейчас, например, я для этого либо смотрю Наследников, либо читаю "Нормандцы в Сицилии", либо гамаю в Корсаров.

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

Нравятся мне Корсары. Хоть они порой и вылетают, и графика там 12-летней давности, а всё же лучше игры с пиратской романтикой пока нет. Что меня, кстати, все эти 12 лет сильно удручает.

А пиратскую романтику с детства люблю. Зачитывался о том, как Генри Морган грабил Панаму, Франсуа Олонэ вырывал сердца, а Титч грабил корабли без единого выстрела чисто на бренде.

Почему мне пофиг на графику в Корсарах? Потому что когда я играю в Корсаров, я сам чувствую себя на борту пиратского корабля. А в моей голове графика отличная =)

Уход от реальности на какое-то время мне помогает освежить голову и с новым взглядом посмотреть на реальность.

А вы куда от реальности сбегаете?)

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

Взял я себе на месячное обучение ученицу.

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

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

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

Почему я вообще её взял на обучение, хотя не переношу «волков», и был практически уверен, что такие люди необучаемы? Потому что она искренне (насколько я смог распознать) хотела именно научиться делать задачи самой, а не просто сделать задачи любым способом, чтоб не выпнули с работы. И искренне не верила, что есть способ устроиться на работу другим способом, кроме как фейковать миддла, т.к. «джуны не нужны».

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

Получилось у меня довольно хреново. Границы я свои ни черта не удержал, контракт тоже. Научил я её буквально парочке небольших тем, в остальное время я пытался без доступа к коду, чисто по видео на созвонах, как-то наталкивать её на правильные мысли, для решения рабочих задач. Как мог старался научить её самостоятельно разбираться со сложностями.

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

Доволен ли я этим опытом? Вполне. Пока по моим границам и контракту не прошлись катком, я не так хорошо их ощущал. И теперь я – Саша Белый Гендальф Белый, и моё менторское кунг-фу стало сильнее.

Повторил бы я такой опыт? Да ну его нахер, вы чо, долбанулись. Я столько времени, как на эту ученицу, трачу обычно на троих. И ещё и чувствовал себя высосанным после каждого созвона (обычно я наоборот на подъёме после занятий).

Если честно – очень переживаю, что от меня щас отпишутся люди по двум причинам:
1) ах ты падла волков поддерживаешь (а я не поддерживаю)
2) ах ты падла ничему не научил за месяц

Задумался тут о том, что за 4 года с 2020 до 2024 мы познали:

1. Мир до ковида
2. Мир во время ковида
3. Мир после ковида, но до СВО
4. Мир во время СВО

И это всё 4 разных мира))

По одному миру в год в среднем. Норм такой темп. Мало какому поколению сломали столько шаблонов, сколько нам. А если учесть, что всё это было при максимально лёгком и быстром обмене информацией между разными точками планеты, то мы – точно уникальное поколение.

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

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

И не забудьте пристегнуться, скорости нынче высокие.

Так, ребятки.

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

Буду раскрывать вопросы:

– какие автотесты бывают, чем отличаются
– зачем и кому они нужны или не нужны, плюсы-минусы
– практические советы по юнит-тестам и UI-тестам

Если интересует что-то ещё – накидывайте в комментарии👇.

Stay tuned.

Зачем мне писать автотесты?

1️⃣ Экономия времени и сил, улучшение прогнозируемости

Без автотестов все мои косяки могут найти в код-ревью (если повезёт), и тогда мне надо фиксить косяк и отправлять обратно на код-ревью – значит, мы потратили лишнее время. А может не повезти – и тогда на код-ревью их не заметят и увидят только на ручных тестах – и тогда мне надо фиксить косяк, отправлять на код-ревью, а потом заново тестировать – так мы потратили ещё больше времени. А время разработки – это потраченные деньги компании.

А я ж хочу накодить фичу побыстрее и спокойно отправить в прод.

Да и при рефакторингах мне куда спокойнее, если вижу, что автотесты при рефакторинге не сломались. Значит либо я всё хорошо порефакторил, либо тесты плохо написали, а с меня взятки гладки =)

Шутка. Сам тесты поломал – сам иди и чини, умник.

Если вы вдруг подумали, что экономия времени будет заметна сразу – хрен там. Это вы увидите только после того, как написанные тесты начнут из раза в раз переиспользоваться. А в первое время будут повышенные затраты времени на написание тестов и на существующий код и на новые фичи. Чем дальше, тем больше будет заметно снижение нагрузки на QA.

Да и не всё можно автоматизировать. Вряд ли у вас получится полностью автоматизировать тестирование какого-то флоу или фичи. И часть нагрузки все равно останется на ручных тестировщиках. Задача автотестов не в том, чтобы полностью снять нагрузку с QA, задача – снизить количество итераций, желательно до одной =).

2️⃣ Улучшение стабильности, уменьшение влияния человеческого фактора

Автотесты один раз написал и наслаждаешься, а QA-шеров корми, пои, спать уложи. Автотесты не устают и не теряют фокус. И не ноют "да вы охренели все задачи за день до конца спринта в тестирование отправлять, я вам чё, осьминог?". Плюс, когда пишешь автотесты — их видят и ревьюят другие, в отличие от ручных тестов, на которых можно схалявить или протупить.

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

3️⃣ Увеличение гибкости и управляемости

С помощью автотестов можно запускать одни и те же тесты на разных версиях API, и на уровне кода подменять любые части приложения, которыми ручному тестировщику управлять сложно/невозможно. Автотесты можно запускать на отдельной ферме устройств, что увеличивает охват и открывает возможность нахождения сложноуловимых багов. А ещё можно влиять на скорость прохождения автотестов с помощью улучшения железа, на котором их запускают. Проапгрейдить кожаный мешок куда сложнее.

4️⃣ Улучшение кода и его понятности

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

5️⃣ Улучшение восприятия компании

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

Какие автотесты вообще бывают?

Часть 1: Unit-тесты

Юнит-тесты нужны для проверки бизнес-логики.
Не привязаны к андроид-платформе: могут запускаться в джава-модулях без андроид-зависимостей. В идеале можно шерить юнит-тесты между андроид и айос-командами практически безболезненно, чисто свифт на котлин поменять.

Юнит-тесты изолированы в рамках одного слоя и его же они собсна и проверяют; все зависимости от других слоёв/модулей подменяются, чтобы они не влияли на результат проверки. Чтоб не было такого: у меня упал слой 1, потому что я накосячил в слое 2. Если слой 1 покрыт юнит-тестами и они упали – значит, косяк именно в нём, иди проверяй, чё ты там нарефакторил.

Юнит-тест проверяет “единицу поведения“ - это может быть, например, юзкейс, или метод репозитория, или класс утилит. Покрывать юнит-тестами можно или только публичный контракт, или все методы класса, включая приватные – тут кому как нравится.
Я предпочитаю не лезть в дела класса и проверять только контракт, а как он реализуется внутри – не моё собачье дело.

Классическая структура юнит-теста:
given → when → then

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

When – вызов реального тестируемого метода.

Then – проверка результата вызова: ассёрты. Можно делать несколько ассёртов в тесте, если результат вызова тестируемого метода к этому располагает.

Важно стараться протестировать ассёртами и тестами все развилки логики if/else. И ни в коем случае не стоит делать if/else в самом юнит-тесте, поскольку иначе при его прохождении/не прохождении будут появляться неоднозначности.
Любое падение юнит-теста должно однозначно свидетельствовать о конкретной проблеме, безо всяких развилок "ну тут или это пошло не так, или вон то".

Юнит-тесты исполняются быстро – из-за того, что они изолированные и у них нет никаких тяжеловесных зависимостей.

Пишутся они тоже быстро, потому что каждый отдельный юнит-тест очень простой, их написание – рутинная работа. Запускать их можно почаще, хоть при каждой локальной сборке, чтобы сразу понимать, где что сломалось.

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

Заметил, что контентные (обучающие) посты набирают мало просмотров и лайков, а не контентные (эмоции, рассуждения) в 2-3 раза больше.

При этом на контентные я трачу в разы больше времени и сил.

Забавная фигня. Я, когда начинал канал, думал, что контент людям важнее =)

И это при том, что я сюда левых людей не набираю, в основном тут только ЦА: начинающие разрабы.

А оно вона как. Интересно, интересно.

Короче я понял))

Расскажите тогда: о чём хотелось бы послушать за жизу? Буду разбавлять контентные посты жизовыми)

Какие автотесты вообще бывают?

Часть 2: Интеграционные тесты

Нужны для проверки правильного взаимодействия разных слоёв/модулей. К примеру, можно протестировать связку Repository → UseCase, или связку Repository → UseCase → Presenter → View. Все остальные слои/модули, которые не проверяются в этом интеграционном тесте, подменяются.

Важно понимать, что интеграционный тест не тестирует UI - этим занимаются UI-тесты, но при этом, в отличие от Unit-тестов, он может исполняться в классах, зависящих от платформы.

В случае android, в этом помогает Roboelectric - быстрый симулятор android на JVM и собственными заглушками (shadows) для классов из android. Также через Roboelectric можно для каждого теста указать target sdk и проводить многие другие манипуляции с платформой.

Интеграционные тесты исполняются медленнее, чем юнит-тесты, поскольку у них больше зависимостей (особенно если используют Roboelectric), и их имеет смысл запускать пореже, например - при каждой отправке коммита в репозиторий.

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

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

Какие автотесты вообще бывают?

Часть 3: UI-тесты

Это тесты, которые проверяют взаимодействие пользователя с интерфейсом приложения: запускается ли нужная логика при кликах по нужным кнопкам, правильно ли работает навигация, правильные ли тексты отображаются, все ли нужные вьюхи отображаются или скрываются и тд.

В UI-тестах мы не вызываем методы приложения напрямую, мы имитируем действия пользователя с интерфейсом приложения.
То есть в этих тестах мы реально кликаем по нашим кнопкам.

Отличия от Unit/интеграционных тестов:

1️⃣ Им для запуска необходим эмулятор/реальное устройство.

2️⃣ Проходят долго. В зависимости от размера приложения, количества тестов и железа, где всё это запускается, прохождение всех UI-тестов может занимать как минуты, так часы и даже дни.

3️⃣ Поскольку UI-тесты — попытка удержать баланс между приближением тестов к реальности и автоматизацией процесса, они довольно хрупкие: их выполнение не гарантируется, из-за того, что появляется зависимость от реальной платформы, которая не всегда предсказуема.

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

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

4️⃣ UI-тест может содержать много шагов и проверок. Их сложно писать и читать. Будет много боли и мата. А настройка CI для UI-тестов у меня когда-то заняла почти год, там столько подводных камней, что из них крепость можно построить.

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