«Приложение Dropbox для Android, насчитывающее более миллиарда загрузок, должно поддерживать высокую планку качества для самых разных юзкейсов и пользователей. Тридцати «ручников» на Android и технологии распознавания #yolo недостаточно для поддержания уверенности в кодовой базе, поэтому мы используем множество подходов к тестированию.
Dropbox предназначен для универсального доступа к файлам на всех пользовательских устройствах, поэтому Android-приложение должно поддерживать просмотр как можно большего количества этих файлов, включая медиафайлы, документы, фотографии и все сочетания этих категорий. Кроме того, функции типа Camera Uploads, автоматически создающей резервные копии важных фотографий, требуют глубокой интеграции с ОС Android, которая значительно изменилась со временем в разных версиях Android. Все это должно гарантированно работать у наших пользователей, не заставляя их беспокоиться о мелочах, потому что последнее, чего хочется человеку — это беспокоиться о том, что он может потерять свои фотографии.
Размер и расположение Android-команды Dropbox менялись на протяжении лет, при этом сохранялась возможность создавать и совершенствовать фичи, которыми мы известны. Как Dropbox это удается укреплять доверие? Далее я расскажу, как совершенствовались наши подходы.
Как было раньше
Автоматизированное тестирование всегда было частью инженерной культуры Dropbox, но на Android оно не было простым. Много лет назад Dropbox инвестировала в тестовую инфраструктуру, которая в значительной степени опиралась на сквозное тестирование. Основываясь на инструментальных тестах Android, мы разработали тест-хелперы для фич приложения по шаблону тестового робота. Это позволило создать большой набор тестов, которые умели имитировать действия пользователя по всему приложению, но при этом требовали значительных затрат.
Как и многие другие проекты Android в то время, приложение Dropbox начиналось как монолитный модуль, но в долгосрочной перспективе это оказалось неэффективным. Была проведена работа по декомпозиции монолита в более модульную архитектуру, но сквозной тестовый набор здесь не был приоритетным, из-за сложных зависимостей. В результате набор так и остался монолитно-ориентированным, а тестовый код не присутствовал рядом с кодом фич, которые он проверял, что приводило к деградации тестового кода.
Длительное время сборки монолитных модулей с большим количеством зависимостей, а также выполнение тестов на эмуляторах в пользовательском окружении CI приводили к тому, что цикл обратной связи для этих E2E-тестов был медленным. Это приводило к тому, что инженеры чувствовали стимул удалять упавшие тесты вместо того, чтобы переписывать их.
Экосистема Android все активнее внедряла автоматизированное тестирование, появлялись такие полезные библиотеки, как Espresso, Robolectric, и поддержка юнит-тестирования, встроенная непосредственно в Gradle, и Dropbox не отставал от этих изменений, переходя от зависимости от E2E-тестов ко все большему количеству юнит-тестов, заполняя нижний слой своей ранее перевернутой пирамиды тестирования. Это стало значительным достижением для покрытия тестами приложения, и позволило внедрить базовые метрики покрытия кода, чтобы поддерживать повышение надежности продукта по мере его развития.
Со временем, когда юнит-тестирование становилось все проще, а инженеры все больше разочаровывались в медленных циклах обратной связи E2E-тестов, наша пирамида тестирования стала смещаться в другую сторону. Мы были уверены в наших юнит-тестах и их инфраструктуре, но наши E2E-тесты устаревали без обслуживания, становясь ненадежными, до такой степени, что мы в основном игнорировали их отказы. Тесты, которым нельзя доверять, в конечном итоге становятся бременем и приносят мало пользы, поэтому мы поняли, что нужно что-то менять.
Что меняли
За последний год мы удвоили внимание к надежности. Инвестировали в тестовую инфраструктуру, чтобы обеспечить не только возможность, но и стимул для написания хороших тестов на всех уровнях пирамиды. Помимо технических инвестиций в код и инструментарий, это потребовало от нас времени на оценку того, что мы тестируем и как мы это тестируем, а также на то, чтобы вся команда лучше понимала, какие инструменты и когда использовать.
Юнит-тестирование
Мы продолжаем тратить бОльшую часть наших усилий на написание юнит-тестов. Это быстрые узконаправленные тесты, которые обеспечивают быструю обратную связь и служат первой линией защиты от регрессий. Мы пишем JUnit-тесты всегда когда это возможно, и возвращаемся к инструментальным тестам когда это необходимо. Связка Robolectric с AndroidX Test позволила нам перенести многие инструментальные тесты в юнит-тесты на основе JVM, что упростило достижение целей по тестовому покрытию.
Кстати, о целях: уровень юнит-тестов это единственный слой, который мы используем для определения покрытия. По умолчанию мы стремимся к 80%-ному покрытию, хотя у нас есть процесс, позволяющий отменить эту цель в случаях, когда юнит-тестирование либо не имеет смысла, либо невыполнимо.
Примечание: Хотя мы используем стандартный инструментарий JaCoCo для оценки тестового покрытия, отсутствие у него глубокого понимания Kotlin создает некоторые проблемы. Например, мы пока не нашли способа сообщать JaCoCo, что сгенерированные аксессоры, toString и hashcode классов данных без поведения не требуют тестового покрытия. Мы экспериментируем и рассматриваем альтернативные варианты, чтобы не писать хрупкие тесты, которые не приносят пользы, но пока мы застряли с переопределениями покрытия для этих кейсов.
Сквозные тесты
За последние несколько месяцев мы возобновили инвестиции в наш автоматизированный набор E2E. Этот набор умеет предупреждать нас о чрезвычайно важных проблемах, которые юнит-тесты просто не в состоянии выявить, например о проблемах интеграции с ОС или неожиданных ответах API. Поэтому мы упорно работали над улучшением инфраструктуры, чтобы инженерам было проще запускать тесты локально, проводили аудит и удаляли некачественные или просроченные тесты, а также работали над документацией и обучением, чтобы обеспечить поддержку инженеров в части тестов E2E.
Как я уже говорил, наши E2E-тесты имитируют перемещение пользователя по всему приложению. Это означает, что задача определения тест-кейсов E2E — это непростая инженерная проблема. Поэтому мы разработали руководство, которое помогает инженерам совместно с партнерами по продукту и дизайну определить тест-кейсы, представляющие реальные сценарии использования.
Недавно мы ввели практику надлежащего определения «Выполнено» (DoD) для задач по разработке. Это представляет собой чеклист пунктов, которые должны быть выполнены, чтобы проект считался «Выполненным», и этот чеклист создается и согласовывается в начале проекта. Наш стандартный чеклист включает описание тест-кейсов E2E для проекта, что гарантирует, что мы добавляем тест-кейсы продуманным образом, принимая во внимание ценность и цель этих тестов, а не ориентируясь на произвольные цифры покрытия.
Скриншоты
Еще одним аспектом, который мы расширили в последние годы, является тестирование скриншотов. Они позволяют нам проверить визуальные регрессии, убедиться, что страницы приложения правильно отображаются в светлом и темном режиме, в разных ориентациях и разных форм-факторах.
В юнит-тестах мы используем Paparazzi для тестирования скриншотов. Это позволяет нам писать быстрые изолированные тесты, и мы считаем, что они лучше подходят для тестирования отдельных страниц или композитных макетов, включая компоненты дизайн-системы.
Мы находим пользу в скриншотах в полнофункциональных инструментальных тестах. Для этого используем собственную библиотеку Dropshots, которая поддерживает скриншот-тестирование на устройствах и эмуляторах. Поскольку Dropshots снимает скриншоты на реальных (или эмулированных) устройствах, это хороший способ проверить системные интеграции, такие как режим дисплея edge-to-edge, и режим окна по умолчанию на устройствах Android 15.
Ручное тестирование
Учитывая все те инвестиции, которые мы сделали в автоматизированное тестирование, можно подумать, что мы не занимаемся ручным тестированием, но даже сегодня это просто невозможно. Существует множество процессов, для которых автотесты было бы слишком сложно написать, либо слишком сложно проверять. Например, у нас есть юнит- и E2E-тесты для проверки поведения при рендеринге содержимого файлов, но программно проверить содержимое файлов может быть сложно, а скриншот-тесты иногда оказываются нестабильными.
Для таких случаев мы используем веб-инструмент для управления тест-кейсами, чтобы поддерживать полный набор ручных тест-кейсов, и сторонний сервис для выполнения тестов перед каждым релизом. Это позволяет выявлять проблемы, для которых мы еще не написали тесты, или которые требуют человеческой оценки.
Планы
Сейчас я занимаюсь расширением функциональности Dropshots для поддержки нескольких конфигураций устройств, что позволит выполнять скриншот-тесты на широком спектре устройств в одном наборе. Поскольку приложение Dropbox работает на разных форм-факторах, будет полезно одновременно запускать набор скриншот-тестов на разных устройствах и эмуляторах, чтобы предотвратить регрессии на редких форм-факторах.
Также мы начинаем экспериментировать с тестированием скриншотов Compose Preview, которое позволит ускорить цикл разработки и использовать их для защиты от регрессий.
Наконец, мы намерены и дальше следить за балансом нужных видов тестов. Балансировка нашей пирамиды гарантирует, что инвестиции в тестирование служат целям надежности, а не погоне за произвольными показателями покрытия.»
