Playdate на Swift
Playdate это портативная консоль с черно-белым экраном и ручкой для кручения. Недавно для нее стало можно разрабатывать на Swift, я попробовал и рассказал на встрече iOS-гильдии про 4 дня экспериментов:
⁃ показываю насколько простое API,
⁃ вою, что нет тестов, дебагера и логера и от этого оч сложно,
⁃ почему дебажить в туалете приходится,
⁃ как купить в России,
⁃ разбираем UnsafeMutablePointer,
⁃ объясняю ручное управление памятью: borrowing, inout, consuming,
https://youtu.be/uzlH3cymCVM
Playdate это портативная консоль с черно-белым экраном и ручкой для кручения. Недавно для нее стало можно разрабатывать на Swift, я попробовал и рассказал на встрече iOS-гильдии про 4 дня экспериментов:
⁃ показываю насколько простое API,
⁃ вою, что нет тестов, дебагера и логера и от этого оч сложно,
⁃ почему дебажить в туалете приходится,
⁃ как купить в России,
⁃ разбираем UnsafeMutablePointer,
⁃ объясняю ручное управление памятью: borrowing, inout, consuming,
https://youtu.be/uzlH3cymCVM
YouTube
Как писать игры на Swift для Playdate
Playdate это портативная консоль с черно-белым экраном и ручкой для кручения. Недавно для нее стало можно разрабатывать на Swift, я попробовал и рассказал на встрече iOS-гильдии в Додо Инжиниринге про 4 дня экспериментов
0:00 Что еще за Playdate
2:22 При…
0:00 Что еще за Playdate
2:22 При…
Запись выше это лишь одна из десятка встреч нашей гильдии, которая проходит каждую неделю, я просто монтажить не успеваю 😄
Если хотите больше такого в своей жизни, то приходите работать в Дринкит — мы ищем iOS-разработчика, который очень любит делать клевые интерфейсы.
Вакансия в Дринкит на iOS
Если хотите больше такого в своей жизни, то приходите работать в Дринкит — мы ищем iOS-разработчика, который очень любит делать клевые интерфейсы.
Вакансия в Дринкит на iOS
Dodo Brands on Notion
Senior iOS-разработчик в Дринкит | Notion
Привет!
Мы Dodo Brands — международная компания, развивающая глобальные фуд-тех бренды: Drinkit и Dodo Pizza.
Мы Dodo Brands — международная компания, развивающая глобальные фуд-тех бренды: Drinkit и Dodo Pizza.
На мобиусе мы участвуем в трех докладах!
- Я расскажу про наш опыт с дополненной реальностью,
- Максим Качинкин про внедрение Compose в Дринкит,
- Екатерина Батеева будет экспертом на докладе про локализацию.
При этом два из трех докладов доступны для всех зарегистрировавшихся на Comunity Day, успевайте подать заявку!
- Я расскажу про наш опыт с дополненной реальностью,
- Максим Качинкин про внедрение Compose в Дринкит,
- Екатерина Батеева будет экспертом на докладе про локализацию.
При этом два из трех докладов доступны для всех зарегистрировавшихся на Comunity Day, успевайте подать заявку!
Telegraph
Community Day на Mobius 2024 Spring
Что входит в Community Day Воркшоп: iOS-приложения под защитой Apple! Или нет? — Дмитрий Истратов (Тинькофф). Архитектурное собеседование — по обе стороны баррикад — Кирилл Володин (Тинькофф). Локализация iOS-приложения за 1$ в 2024 году — Александр Гращенков…
Forwarded from Dodo Engineering
Совсем скоро пройдёт Mobius — крутейшая техническая конференция для мобильных разработчиков. Идёте на неё или планируете подключиться онлайн? Приходите послушать участников нашей команды! 🤩
23 мая с 12:15 до 13:00 Макс Качинкин, наш Android Tech Lead, расскажет о тех кейсах-вызовах, с которыми его команда столкнулась при переносе проекта с Compose на View, и о том, как они справлялись с этими вызовами.
В тот же день, с 14:00 до 15:00, Миша Рубанов, Head of Mobile & People Lead, поделится опытом приготовления 3D-пиццы. Покажет, как решить все интерфейсные проблемы, с которыми он столкнулся. В общем вы узнаете всё о том, как прикрутить AR к вашему приложению буквально за один вечер. 😮
Екатерина Батеева, iOS Developer, в этот день будет экспертом на докладе о локализации iOS-приложений в 2024 году, который можно будет послушать с 12:55 до 13:35. Кстати, если вам интересно, чем занимаются эксперты на конференциях, пишите — расскажем в одном из следующих постов.
В оффлайн-дни конференции, 31 мая и 1 июня, Катю можно будет встретить очно в кластере «Ломоносов», находящемся по адресу Раменский бульвар, 1. Приходите пообщаться! 👀
23 мая с 12:15 до 13:00 Макс Качинкин, наш Android Tech Lead, расскажет о тех кейсах-вызовах, с которыми его команда столкнулась при переносе проекта с Compose на View, и о том, как они справлялись с этими вызовами.
В тот же день, с 14:00 до 15:00, Миша Рубанов, Head of Mobile & People Lead, поделится опытом приготовления 3D-пиццы. Покажет, как решить все интерфейсные проблемы, с которыми он столкнулся. В общем вы узнаете всё о том, как прикрутить AR к вашему приложению буквально за один вечер. 😮
Екатерина Батеева, iOS Developer, в этот день будет экспертом на докладе о локализации iOS-приложений в 2024 году, который можно будет послушать с 12:55 до 13:35. Кстати, если вам интересно, чем занимаются эксперты на конференциях, пишите — расскажем в одном из следующих постов.
В оффлайн-дни конференции, 31 мая и 1 июня, Катю можно будет встретить очно в кластере «Ломоносов», находящемся по адресу Раменский бульвар, 1. Приходите пообщаться! 👀
Какой сейчас год?
Уже смотрели WWDC20? Apple показали новую технологию — App Clips. Готов поспорить, мини-приложения станут очень популярными! Мы поспешили разработать свой App Clip и написали статью, в которой рассказываем, как мы придумывали фичу, с какими проблемами столкнулись при разработке, и делимся аналитикой после запуска.
https://habr.com/ru/companies/dododev/articles/821009
Уже смотрели WWDC20? Apple показали новую технологию — App Clips. Готов поспорить, мини-приложения станут очень популярными! Мы поспешили разработать свой App Clip и написали статью, в которой рассказываем, как мы придумывали фичу, с какими проблемами столкнулись при разработке, и делимся аналитикой после запуска.
https://habr.com/ru/companies/dododev/articles/821009
Хабр
Как мы искали применение App Clip… и нашли?
Привет! Меня зовут Кирилл. Моя команда в Додо отвечает за развитие на международных рынках. Мы часто заигрываем с новыми технологиями и делаем прикольные фичи, такие как Live Activities и AI-пицца ....
Доступность в 2ГИС
Не могу не поделиться статьей про доступность в 2ГИС.
- Есть пример кода как работать с adjustable-каруселью.
- Как писать юнит-тесты для скринридера. Я бы через снепшоты текста сделал, но самое главное — подход.
- В целом про интерфейс навигационного приложения, когда визуал расходится с описанием для скринридера
https://habr.com/ru/companies/2gis/articles/826360/
Не могу не поделиться статьей про доступность в 2ГИС.
- Есть пример кода как работать с adjustable-каруселью.
- Как писать юнит-тесты для скринридера. Я бы через снепшоты текста сделал, но самое главное — подход.
- В целом про интерфейс навигационного приложения, когда визуал расходится с описанием для скринридера
https://habr.com/ru/companies/2gis/articles/826360/
Хабр
Адаптируем VoiceOver для людей
Меня зовут Женя Тютюев, я iOS-разработчик в компании 2ГИС. Хочу поделиться, как адаптировал наше приложение под VoiceOver: делюсь историей про сдвиг парадигмы и как перешёл из стадии «делать,...
Как продать доступность бизнесу
Вопрос из чата: как продать эту вашу доступность бизнесу? Вопрос частый, делюсь ссылками.
От трети до половины ваших пользователей настраивает приложение под себя через настройки доступности. Возможно, двадцати-тридцати летним разработчикам это не так очевидно, но реальный мир такой. Вот это настоящие цифры, наши исследования подтверждают.
Если конкретно про скринридер и разные такие технологии, то работа с деревом доступности в интерфейсе дает покрытие нескольким технологиям: VoiceOver, Switch Control, Voice Control, «чтение экрана» и «чтение выбранного». В сумме это около 4% пользователей. Про это скоро выйдет статья, но близко к этому в докладе https://youtu.be/72tAiNzrHxM?si=yPdVRwQw1wPOKNsO
Начать можно собрав аналитику со старта приложения и целевого действия: увидите количество и конверсию. Посмотреть что собирать и как можно в этой библиотеке. https://github.com/chrs1885/Capable
Уговаривать бизнес обычно нужно для масштабирования практик, сделать нормально можно и только на уровне разработчиков. Тут как с юнит-тестами: для начала нужно просто научиться работать с этим разработчикам, потом может оказаться, что у бизнеса ничего спрашивать и не нужно. Одних навыков разработчиков попрой достаточно, чтобы сильно повысить качество. Книжка нацелена именно на это https://rubanov.dev/a11y-book/
Вопрос из чата: как продать эту вашу доступность бизнесу? Вопрос частый, делюсь ссылками.
От трети до половины ваших пользователей настраивает приложение под себя через настройки доступности. Возможно, двадцати-тридцати летним разработчикам это не так очевидно, но реальный мир такой. Вот это настоящие цифры, наши исследования подтверждают.
Если конкретно про скринридер и разные такие технологии, то работа с деревом доступности в интерфейсе дает покрытие нескольким технологиям: VoiceOver, Switch Control, Voice Control, «чтение экрана» и «чтение выбранного». В сумме это около 4% пользователей. Про это скоро выйдет статья, но близко к этому в докладе https://youtu.be/72tAiNzrHxM?si=yPdVRwQw1wPOKNsO
Начать можно собрав аналитику со старта приложения и целевого действия: увидите количество и конверсию. Посмотреть что собирать и как можно в этой библиотеке. https://github.com/chrs1885/Capable
Уговаривать бизнес обычно нужно для масштабирования практик, сделать нормально можно и только на уровне разработчиков. Тут как с юнит-тестами: для начала нужно просто научиться работать с этим разработчикам, потом может оказаться, что у бизнеса ничего спрашивать и не нужно. Одних навыков разработчиков попрой достаточно, чтобы сильно повысить качество. Книжка нацелена именно на это https://rubanov.dev/a11y-book/
appt.org
Appt.org | A guide for making apps accessible | Appt
Appt.org empowers developers and organizations to build accessible apps for everyone by offering current stats on the use of accessibility features, code documentation for iOS, Android and other platforms, guidelines, tips and how-to's.
Скорость Compose
Дринкит на Android всю карточку продуктал сделал на Compose, это был большой и смелый эксперимент. По большей части он был успешным, но в конце оказалось, что первый раз экран открывается с ощутимой задержкой, потому что библиотека только в этот момент загружается и это видно визуально.
В деталях Максим Качинкин рассказал на Мобиусе, видео уже доступно!
Дринкит на Android всю карточку продуктал сделал на Compose, это был большой и смелый эксперимент. По большей части он был успешным, но в конце оказалось, что первый раз экран открывается с ощутимой задержкой, потому что библиотека только в этот момент загружается и это видно визуально.
В деталях Максим Качинкин рассказал на Мобиусе, видео уже доступно!
YouTube
Максим Качинкин — Переходишь на Compose? Не спеши!
Ближайшая конференция — Mobius 2024 Autumn, 11 октября (Online), 19–20 октября, Санкт-Петербург. Подробности и билеты: https://jrg.su/Yu6KNJ
— —
Скачать презентацию с сайта Mobius — https://jrg.su/Hn17D4
Вас влечет мир Jetpack Compose или вы уже на пороге…
— —
Скачать презентацию с сайта Mobius — https://jrg.su/Hn17D4
Вас влечет мир Jetpack Compose или вы уже на пороге…
Платим за написание удаление кода
Мы, разработчики, сидим и код какой-то пишем. Пишем, пишем, его всё больше и больше, а старое почти не удаляем. А когда удаляем то не ясно «а всё ли удалили» — Xcode никак не подсказывает, что где-то какие-то хвостики остались.
В итоге целая пачка проблем:
- Иногда при написании нового кода приходится что-то актуализировать в старом, а он может быть вообще нигде не используется и просто мертвым грузом лежит. Это мы время теряем.
- Иногда при подготовке кода к новым фичам что-то рефачим и случайно удаляем вызов важного метода. Это мы баги заносим.
- Постоянно билдим проект локально и на CI, и в том числе билдится и вот такой мертвый код. Это мы время теряем.
8 июня 2023, то есть год назад, я затащил в проект Додо Пиццы тулзу Periphery — она анализирует весь наш код и говорит «вот тут чет лишнее осталось и вот там кусок бесхозный стал». Её одобрение — одна из обязательных проверок на CI при влитии ПРов.
Я не знаю сколько нового мертвого кода она запретила вливать (хз как посчитать) и сколько багов предотвратила. Но у нас тут с мертвой точки сдвинулась война с брошенными фичатоглами и тулза сильно помогла при их выпиле. И продолжает помогать.
Сначала я скормил ей весь наш проект и она выдала мне около 3000 варнигов. Я понял, что устранить их за раз не вариант. Тогда я загнал все наши модули под карантин, а потом аккуратно раскарантинивал и устранял варнинги. Где-то месяца 2-3 назад я передал задачу другой разработчице, Маше, и где-то полтора месяца назад она закончила выносить все модули из карантина. Но это только первый этап был.
Вторым этапом стал тюнинг настроек Периферии: мы попросили ругаться ещё и на публичные проперти, если они не юзаются или если им нет необходимости быть публичными, так как никто снаружи их не юзает. Это дало нам ещё 3000 варнингов. Маша их устраняла последние полтора месяца.
В общем и целом спустя год мы закончили удалять бесполезный мертвый код и теперь его никак нельзя занести в проект.
Что это нам дало:
- Перестали тратить время на поддержание кода, который никогда не выполняется на проде.
- Сократили количество легаси. Вот прям сегодня после рефактора очередной кусок удалил по наводке периферии, потому что он перестал использоваться.
- Проект стал билдиться быстрее. Пруфов не будет.
- Ускорили и удешевили билды на CI.
Итог
С самого начала проекта мы считали количество строк кода по мере раскарантинивания проекта. Цифры такие:
Удалили: 27к
Добавили: 5к
Это много или мало? Давайте посмотрим на аналитику сонара:
Lines: 400к
Lines of Code: 250к
Получается мы удалили где-то 5-10% нашего приложения.
Что дальше
Можно подключить к периферии ещё и тесты — там много моков валяется бесполезных и хелперов лишних, на которые мы тож тратим время и силы.
Мы, разработчики, сидим и код какой-то пишем. Пишем, пишем, его всё больше и больше, а старое почти не удаляем. А когда удаляем то не ясно «а всё ли удалили» — Xcode никак не подсказывает, что где-то какие-то хвостики остались.
В итоге целая пачка проблем:
- Иногда при написании нового кода приходится что-то актуализировать в старом, а он может быть вообще нигде не используется и просто мертвым грузом лежит. Это мы время теряем.
- Иногда при подготовке кода к новым фичам что-то рефачим и случайно удаляем вызов важного метода. Это мы баги заносим.
- Постоянно билдим проект локально и на CI, и в том числе билдится и вот такой мертвый код. Это мы время теряем.
8 июня 2023, то есть год назад, я затащил в проект Додо Пиццы тулзу Periphery — она анализирует весь наш код и говорит «вот тут чет лишнее осталось и вот там кусок бесхозный стал». Её одобрение — одна из обязательных проверок на CI при влитии ПРов.
Я не знаю сколько нового мертвого кода она запретила вливать (хз как посчитать) и сколько багов предотвратила. Но у нас тут с мертвой точки сдвинулась война с брошенными фичатоглами и тулза сильно помогла при их выпиле. И продолжает помогать.
Сначала я скормил ей весь наш проект и она выдала мне около 3000 варнигов. Я понял, что устранить их за раз не вариант. Тогда я загнал все наши модули под карантин, а потом аккуратно раскарантинивал и устранял варнинги. Где-то месяца 2-3 назад я передал задачу другой разработчице, Маше, и где-то полтора месяца назад она закончила выносить все модули из карантина. Но это только первый этап был.
Вторым этапом стал тюнинг настроек Периферии: мы попросили ругаться ещё и на публичные проперти, если они не юзаются или если им нет необходимости быть публичными, так как никто снаружи их не юзает. Это дало нам ещё 3000 варнингов. Маша их устраняла последние полтора месяца.
В общем и целом спустя год мы закончили удалять бесполезный мертвый код и теперь его никак нельзя занести в проект.
Что это нам дало:
- Перестали тратить время на поддержание кода, который никогда не выполняется на проде.
- Сократили количество легаси. Вот прям сегодня после рефактора очередной кусок удалил по наводке периферии, потому что он перестал использоваться.
- Проект стал билдиться быстрее. Пруфов не будет.
- Ускорили и удешевили билды на CI.
Итог
С самого начала проекта мы считали количество строк кода по мере раскарантинивания проекта. Цифры такие:
Удалили: 27к
Добавили: 5к
Это много или мало? Давайте посмотрим на аналитику сонара:
Lines: 400к
Lines of Code: 250к
Получается мы удалили где-то 5-10% нашего приложения.
Что дальше
Можно подключить к периферии ещё и тесты — там много моков валяется бесполезных и хелперов лишних, на которые мы тож тратим время и силы.
GitHub
GitHub - peripheryapp/periphery: A tool to identify unused code in Swift projects.
A tool to identify unused code in Swift projects. Contribute to peripheryapp/periphery development by creating an account on GitHub.
Пиццы в дополненной реальности
Теперь в приложении несколько пицц можно посмотреть в дополненной реальности во всех размерах и на всех платформах.
⁃ Россия: Пепперони, Песто, Пепперони Фреш и Додо
⁃ Турция: Чикен Бомбони, Песто, Суджук, Суджук Фреш и Додо
⁃ Дубай: Пепперони и Ранч Суприм Чикен.
Модельки реалистичные, размеры настоящие. Все это открывается через мягонькую шторку, а сами карточки получили новые сочные фотки.
Теперь в приложении несколько пицц можно посмотреть в дополненной реальности во всех размерах и на всех платформах.
⁃ Россия: Пепперони, Песто, Пепперони Фреш и Додо
⁃ Турция: Чикен Бомбони, Песто, Суджук, Суджук Фреш и Додо
⁃ Дубай: Пепперони и Ранч Суприм Чикен.
Модельки реалистичные, размеры настоящие. Все это открывается через мягонькую шторку, а сами карточки получили новые сочные фотки.
Мы научились делать 3д массово
Самым сложным было наладить процесс по созданию моделек, но текущий результат чумовой: сделать одну модель можно за 30 минут, весить она будет около 3 мб (это 2 фото на айфоне), процесс автоматизирован и модельки сразу готовятся для iOS и Android.
Все это особенно важно, если прикинуть масштаб: сейчас мы сделали 10 моделей в разных странах, но они доступны в 3 размерах и на две платформы, т.е. это уже 60 моделек, а нужны будут тысячи!
Создавать их стало настолько просто, что позже процессом будут заниматься ребята из фотолаборатории, а не разработчики. Для этого мы разработали приложение для пакетой обработки фоток, участие человека при этом нужно ну на минуту максимум на минуту для одной пиццы и в итоге весь процесс получается быстрее, чем ретушировать фото!
Самым сложным было наладить процесс по созданию моделек, но текущий результат чумовой: сделать одну модель можно за 30 минут, весить она будет около 3 мб (это 2 фото на айфоне), процесс автоматизирован и модельки сразу готовятся для iOS и Android.
Все это особенно важно, если прикинуть масштаб: сейчас мы сделали 10 моделей в разных странах, но они доступны в 3 размерах и на две платформы, т.е. это уже 60 моделек, а нужны будут тысячи!
Создавать их стало настолько просто, что позже процессом будут заниматься ребята из фотолаборатории, а не разработчики. Для этого мы разработали приложение для пакетой обработки фоток, участие человека при этом нужно ну на минуту максимум на минуту для одной пиццы и в итоге весь процесс получается быстрее, чем ретушировать фото!
Управление ожиданием
Самым интересным в интерфейсе было спрятать загрузку модельки. Она весит 3 мб, что достаточно мало, но качается все равно не моментально. При этом в феврале мы уже делали эксперимент с пиццей-сердце, из которой узнали, что в человек тратит от 3 до 8 секунд на размещение пиццы на столе, а значит, что у нас есть время скачать пиццу незаметно.
В итоге мы запускаемся с закрытой коробкой, которая скрывает загрузку модели внутри себя, но сразу показываем трехмерную коробку, которая привязанна к камере, что достаточно понятно подсказывает что делать. К моменту, когда человек положит коробку моделька скорее всего скачается, а если не скачалась, то мы подождем и не будем открывать коробку.
UX, который никто не заметит и в Фигме не нарисуешь, но вы теперь знаете как там хитро!
Самым интересным в интерфейсе было спрятать загрузку модельки. Она весит 3 мб, что достаточно мало, но качается все равно не моментально. При этом в феврале мы уже делали эксперимент с пиццей-сердце, из которой узнали, что в человек тратит от 3 до 8 секунд на размещение пиццы на столе, а значит, что у нас есть время скачать пиццу незаметно.
В итоге мы запускаемся с закрытой коробкой, которая скрывает загрузку модели внутри себя, но сразу показываем трехмерную коробку, которая привязанна к камере, что достаточно понятно подсказывает что делать. К моменту, когда человек положит коробку моделька скорее всего скачается, а если не скачалась, то мы подождем и не будем открывать коробку.
UX, который никто не заметит и в Фигме не нарисуешь, но вы теперь знаете как там хитро!
50% покрытие тестами
Хотел написать пост, что мы покрыли тестами больше 50% проекта за 4 года и какие выводы накопились, но там опять на статью вышло, а значит быстро не получится.
Поэтому можем наоборот — поспрашивайте в комментах что интересно про любые автотесты, я поотвечаю, а потом в статью заберу ответы, чтобы самое волнующее разобрать.
Как можно получать ускорение от тестов? Какие писать или не писать? Какая либа для автомоков лучшая?
Хотел написать пост, что мы покрыли тестами больше 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 месяца на фуллтайм для обучения команды за очень дорого, а потом еще раз самому подумать что я на самом деле хочу от тестов.
- Строго следить за структурами данных, потому что они позволяют избежать пачки ошибок раньше, чем это покажут тесты.
- Логировать все зависимости, чтобы при проблемах с прода можно было легко восстановить тест.
План такой:
- Как можно раньше втащить скриншот и снепшот-тесты, как можно чаще снепшотить данные, например, сеть и аналитику. 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 месяца на фуллтайм для обучения команды за очень дорого, а потом еще раз самому подумать что я на самом деле хочу от тестов.
- Строго следить за структурами данных, потому что они позволяют избежать пачки ошибок раньше, чем это покажут тесты.
- Логировать все зависимости, чтобы при проблемах с прода можно было легко восстановить тест.
www.pointfree.co
Dependencies
Dependencies can wreak havoc on a codebase. They increase compile times, are difficult to test, and put strain on build tools. Did you know that Core Location, Core Motion, Store Kit, and many other frameworks do not work in Xcode previews? Any feature touching…
Размеры пиццы в AR
Теперь выбирать размер пиццы можно в дополненной реальности. Анимацию изменения специально не добавляли, чтобы было видно разницу между размерами.
И вот так наконец-то видно, насколько большая больше маленькой!
Теперь выбирать размер пиццы можно в дополненной реальности. Анимацию изменения специально не добавляли, чтобы было видно разницу между размерами.
И вот так наконец-то видно, насколько большая больше маленькой!