Управление ожиданием

Самым интересным в интерфейсе было спрятать загрузку модельки. Она весит 3 мб, что достаточно мало, но качается все равно не моментально. При этом в феврале мы уже делали эксперимент с пиццей-сердце, из которой узнали, что в человек тратит от 3 до 8 секунд на размещение пиццы на столе, а значит, что у нас есть время скачать пиццу незаметно.

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

UX, который никто не заметит и в Фигме не нарисуешь, но вы теперь знаете как там хитро!

50% покрытие тестами

Хотел написать пост, что мы покрыли тестами больше 50% проекта за 4 года и какие выводы накопились, но там опять на статью вышло, а значит быстро не получится.

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

Как можно получать ускорение от тестов? Какие писать или не писать? Какая либа для автомоков лучшая?

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

Если бы начинал всё заново, что сделал бы по другому?

План такой:
- Как можно раньше втащить скриншот и снепшот-тесты, как можно чаще снепшотить данные, например, сеть и аналитику. Golden-master тестирование стало паттерном, который я часто применяю и к которому везде стремлюсь, но в начале про него не знал.

- Мокать сеть только через URLProtocol

- Сравнивать объекты только через XCTAssertNoDifference

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

- Понять, что тестировать надо через зависимости, эта статья перевернулся представление https://www.pointfree.co/collections/dependencies

- Тесты должны быть как можно более sociable, а не в изоляции. Хорошо тут перепридумано словао «интеграционные» тут https://matklad.github.io/2022/07/04/unit-and-integration-tests.html

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

- Не использовать Quick, потому что он упрощает написание, но усложняет поддержку. Я орал, когда тесты не смогли скомпилиться от большой глубины вложенности клож или когда скриншот-тест не смог прочитать картинку, потому что мы превысили максимальный размер названия файла!

- Подумать про стратегию тестирования. Это невозможно сделать в начале, если нет опыта покрытия тестами, но это в итоге сильно влияет на все, что планируете делать. Например, у нам в ключемов сценарии есть несколько этапов: выбор локации, меню, кастомизация в карочке продукта, синхронизация с бэкендом в корзине, связные параметры на чекауте и разные способы оплаты при оплате. Все это должно стать отдельными модулями, с отделенными зависимостями и описанными кейсами для интеграционных тестов. Если бы мы пошли так, понимали как упрощать сетап тестов, написали клевые ассерты и зависимости, то нашли бы больше багов и быстрее бы двигались. Увы, для этого надо было 4 года писать тесты и набить все шишки.

- Писать UI-тесты разработчиками, но только для того, чтобы они сами могли выбирать на каком уровне тестировать фичу. В итоге чаще бы писали интеграционные тесты, которые стабильней и быстрее, чем UI-тесты.

- Все места, которые непонятно было как тестировать описывать тесткейсами на русском. Сразу бы стало понятно что я на самом деле хочу. Дальше перевел бы это в обязательные приемочные критерии для задачи (и тоже стало бы понятно что мы от них хотим на самом деле)

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

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

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

- Логировать все зависимости, чтобы при проблемах с прода можно было легко восстановить тест.

Названия релизов

На самом деле почти все версии Додо Пиццы имеют внутренние названия.

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

А какие у вас ритуалы для разбавления рутины?

В 20:00 по Мск рассказываю про тесты:
- как прошли наши 4 года с тестами
- какие типы тестов сейчас пишем
- как тесты помогают на ревью
- посмотрим на настоящие примеры

Приходите, сессия открытая

🔥 Рецепты пиццы и кода от QA.GURU – уже в 20:00 по МСК!

Сегодня у вас есть уникальная возможность прокачать свои навыки в автотестировании! Хотите писать код, который работает без багов и масштабируется, как идеальная пицца с каждым новым слоем? Тогда обязательно приходите на открытый урок "Стратегия автотестирования для iOS-приложений", где мы на примере Додо Пиццы покажем современный подход к автотестам. Будет вкусно и продуктивно 😋

Михаил Рубанов – эксперт по accessibility, автор книги "Про доступность iOS" и Head of mobile в Dodo Engineering, раскроет все секреты, а вы:

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

Не упустите шанс сегодня в 20:00 по МСК научиться готовить качественный код так же легко, как пиццу!

Вот и запись. В конце много вопросов на разные темы про тестирование

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

Но все это очень сильно разбивается об реализацию и проблемы поддержки. Каждая из них может показаться незначительной, но иногда стреляет ВСЕ РАЗОМ.

⁃ Спецификация описывается через кложи, а они медленно компилятся. В итоге очень большую спецификацию не написать — в какой-то момент просто отваливаются на вложенности. И это вроде даже хорошо, потому что слишком большие спеки писать не стоит, но вы не сможете спрогнозировать скорость компилятора и отломается тогда, когда вам осталось написать пару строчек. И что, в такой момент все переписывать?
⁃ Так же и в обратную сторону: если вы вдруг ошиблись в коде, то компилятору будет очень сложно сказать где именно ошибка и вы останетесь наедине с буквами, будто работает не в умной среде разработки, а прям в блокноте. Поспрашивал коллег — все дружно кивают на этом пункте.
⁃ Писать спеку удобно, а вот работать с ней — нет. При отладке вам нужен коротки воспроизводимый тест на 10 строк, но в спеке для одного кейса приходится работать со всем файлом строк на 300-500 минимум, дебажить это неудобно, постоянно скачите из одного места в другое.
⁃ Интеграция в хкод никакая. Чтобы прогнать один тест из спеки надо писать префикс f, это приводит к рекомпиляции, которая долгая (смотри пункт 1). Но даже с префиксом неудобно, потому что файл очень большой, его легко забыть и без дополнительного тулинга в виде линтера или мониторинга количества тестов вы постоянно на это будете напарываться.
⁃ В снепшотах-тестах сталкивались с тем, что суммарное название теста получается длиннее максимального размера названия файла :DD

При этом подлость в том, что писать на Quick действительно удобно! На графике видно, как быстро мы начали наращивать количество спек в Quick, но уже через пару лет энтузиазм пропал и мы стали отказываться. Переписываем тесты через ChatGPT: иногда срабатывает так, что ничего править не надо (иногда и полная чушь, я тут без AI-оптимизма).

SwiftTesting тоже клевый по синтаксису (можно отделить интеграционные и скриншот-тесты!), но очень медленный из-за макросов. Не везет iOS с фреймворками для тестирования.

После этого остается вопрос «а как быть то», но про хороший DSL как-нибудь в другой раз

🚀 Как автоматизировать процесс разработки и сделать жизнь android-разработчика проще? Ответы на эти вопросы найдете на Podlodka Android Crew с 16 по 20 сентября!

Podlodka Crew — это онлайн-конференции для IT-специалистов, которые фокусируются на практической пользе. Сессии проходят утром и вечером, чтобы вы могли совмещать их с работой.

Вас ждут:

- Detekt. Продвинутый уровень: Григорий Шимичев из Додо Инжиниринг поможет вспомнить базовые возможности detekt и познакомиться с продвинутыми. Поговорим о пользе статического анализа кода и зачем этим заниматься.
- Пришёл, увидел, наплагинил: Павел Стрельченко из HeadHunter расскажет, как разработка плагинов для IntelliJ IDEA может стать вашей скрытой суперсилой.
- Автоматизация экспорта токенов из Figma: Никита Яцкивский из Магнит поделится опытом автоматизации экспорта дизайнерских токенов в код, что значительно ускоряет работу над проектом.
- Генерация шаблонного кода с помощью Geminio: Евгений Мельцайкин из СКБ Контур расскажет, как избавиться от повторяющегося кода и сосредоточиться на важных задачах.

Подключайтесь к Podlodka Android Crew, чтобы получить самые актуальные знания и практические советы! Билеты со скидкой: https://podlodka.io/droidcrew

А промокод сообщества android_crew_12_OriyZS даёт скидку еще в 500 руб🥳

Ближайшая Android-подлодка про инструменты, на ней Григорий Шимичев из Дринкита расскажет про detekt, приходите послушать!

Genshin Impact

Вчера началась наша самая большая коллаборация — с Геншином. В пиццериях есть особенные пиццы, напитки, коробки, стенды и брелоки с персонажами.

В приложении мы стилизовали карточку продукта, добавили большую AR-сцену и впереди еще один большой секретик. Смотрите как красиво!