Factory Mode — как сбросить настройки?
Иногда во время работы смартфона может появиться непонятное меню на английском или китайском языке. Оно называется Factory Mode. Эта статья расскажет о том, что это такое, зачем оно нужно и как из него выйти.
Что такое и зачем нужен Factory Mode
Второе название – Factorykit test. На русский язык эту функцию можно перевести как «заводской режим». Это часть прошивки смартфона на «Андроид», позволяющая вручную проверить работоспособность компонентов устройства перед загрузкой системы.
Рассматриваемых режим запускается в 2 случаях: самостоятельно при невозможности загрузки системы из-за повреждения необходимых файлов и системного раздела целиком (обычно после неудачной перепрошивки) и по требованию пользователя.
Во втором случае запустить заводской режим можно, в зависимости от модели смартфона одним из 2 способов:
Для каждого телефона предусмотрена своя комбинация и поэтому следует попробовать оба варианта.
Перед запуском заводского режима рекомендуется полностью зарядить батарею или подключить телефон к зарядному устройству. Иначе при отключении в этом режиме может повредиться системный раздел и тогда потребуется перепрошивка смартфона.
Функции Factory Mode
После входа в factory mode на экране отобразится главное меню, состоящее из 5-12 пунктов. Для навигации используются кнопки громкости (вверх-вниз) и питания («Выбрать»).
Расшифровка наиболее часто встречающихся пунктов меню:
Результаты тестов выводятся посредством 2 сообщений: pass (удачно) и fail (провал).
Выход из Factory Mode
Чтобы выйти из factory mode нужно:
Если загрузка обрывается в самом начале повторным появлением заводского режима, то поврежден системный раздел и нужна перепрошивка.
Подводя итог, можно сказать, что заводской режим – полезная функция, позволяющая проверить состояние устройства. Пугаться появления ее меню не нужно, обычно это происходит случайно. Чтобы выйти из этого режима достаточно в меню выбрать пункт «Reboot».
Что делать в Factory Mode на Андроиде
Каждый обладатель смартфона с ОС Андроид может столкнуться с такой ситуацией, что ему придется воспользоваться режимом Factory Mode и не будет ясно, что делать. Этот режим не что иное, как заводские настройки и использовать его можно в любой момент для теста гаджета. С помощью Factory Mode на Андроид можно тестировать что угодно, звук, клавиши, яркость подсветки. Так же можно очистить кэш, откатить операционную систему устройства до заводских настроек, откалибровать девайс, очистить флешку и многое другое.
Меню Factory Mode на английском языке, поэтому, когда экспериментируете с его возможностями соблюдайте осторожность, иначе есть вероятность потерять все данные на вашем Андроид гаджете.
У производителей смартфонов, не смотря на то, что установлена одна ОС, меню может несколько отличаться. Но в большинстве своем в Factory Mode содержат стандартный набор пунктов:
Когда завершается тест какой-либо системы смартфона появляется одна из двух надписей Test Pass или Test Fail. В первом случае тестирование проведено успешно, а во втором случае провалено.
Когда появляется Factory Mode
Данное меню Factory Mode появляется на Android в двух случаях:
Обычно второй случай характерен для аппаратов тех умельцев, которые самостоятельно пытаются перепрошить девайс, не имея для этого должного опыта и навыков или получить Root-права. Похожим режимом является Fastboot Mode, описанный мной ранее.
На смартфонах различных производителей меню Factory Mode вызывает разными способами. В основном это верхнее или нижнее положение качелей громкости с одновременным нажатием клавиши включения. Иногда встречаются сочетания трех клавиш: громкости, включения и «домой».
Проделав эту нехитрую манипуляцию, открываете меню настроек. У меня получилось войти в Factory Mode применив одновременное нажатие клавиши громкости вверх и кнопки включения. На новых моделях смартфонов перемещаться по меню можно при помощи сенсорного экрана, но наиболее часто используется для навигации качелька громкости. Для того чтобы войти в выбранную директорию просто нажмите клавишу включения.
Как покинуть Factory Mode
При штатном запуске этого меню Factory Mode выход из него не доставит затруднений.
Поэтому перед началом любого вмешательства в программное обеспечение делайте резервную копию данного раздела, для того чтобы не думать о том, что делать с Factory Mode. Это поможет спасти нервы и сэкономить время на реанимацию вашего Андроид устройства. Но даже это не убережет от похода в сервис центр, так как только там имеется необходимое оборудование.
Мой совет прост: не имея опыта свершения подобных операций, не пытайтесь экспериментировать. Подобные попытки – это деньги, выброшенные на ветер.
Factory Mode на андроиде — что делать, если случайно зашел
Операционная система андроид предоставляет гораздо большие возможности и функции, чем кажется. Простой пользователь видит лишь верхушку айсберга, те настройки, которые скрыты далеко, ему неподвластны. Большинство людей не пользуется даже третьей частью от всех тех возможностей, которые предоставляет их телефон. В этом материале будет рассмотрен Factory Mode на андроиде, что это и какие тесты аппаратной части устройства он предполагает.
Что такое Factory Mode на андроиде
Factory Mode в переводе с английского дословно означает «фабричный режим». Также его называют «заводским режимом». Он имеет ряд кардинальных отличий от всеми известного Recovery Mode, который предназначен для восстановления телефона, его перепрошивки и очитки кэша или всех данных.
Внешний вид обычного фактори моде
Заводской режим представляет собой скрытую утилиту для разработчиков и производителей, целью которой является тестирование основных настроек, программных и аппаратных особенностей гаджета. Программа вшита в операционную систему и доступна для входа только через определенную комбинацию действий.
К сведению! Заводской режим, как и рекавери, состоит из пунктов меню, перемещаться по которым необходимо с помощью клавиш увеличения и уменьшения громкости. Выбор происходит путем нажатия кнопки «Питание». Количество пунктов меню зависит от модели и производителя.
Заводское меню тестирования на разных телефонах выглядит по-разному
Как войти в Factory Mode на андроиде
Стоит сразу же сказать, что обнаружить данную утилиту можно далеко не в каждом телефоне. Часть производителей смартфонов и планшетов попросту отказались от его использования, так как тестирование в стенах фабрики производится специальными средствами или комбинациями клавиш.
Если в телефоне человека есть фактори мод, то наиболее вероятно, что он запускается:
Важно! При попытке входа телефон или планшет должен быть выключенными, а кнопки нажиматься одновременно. Также нужно быть аккуратным, так как эти комбинации могут открыть совсем не то меню.
Распространенная комбинация входа в режим
Что делать, если случайно вошел в режим тестирования на андроиде: как выйти
Иногда можно непроизвольно войти в Factory Mode на андроиде, что делать в такой ситуации? На самом деле все очень просто, пугаться не стоит, но и нажимать на все подряд не следует. Так можно изменить какие-нибудь важные настройки или попросту испугаться громкого писка, включив тестирование звукового модуля.
Обычно внизу списка есть пункт Reboot. Он есть везде и не зависит от версии операционной системы, производителя устройства или его модели. Переводится он как «Перезагрузка». Необходимо просто выбрать его, пройдя все пункты с помощью кнопки «Уменьшение громкости» и нажать на «Питание». Телефон автоматически перезагрузится и запустится в обычном режиме.
Обратите внимание! Часто люди случайно переходят в Factory Mode, когда нажимают не только кнопку включения, но и панель громкости при подаче питания одной рукой.
Выход из фактори мода путем выбора пункта «Reboot»
Виды тестов в Factory Mode на андроиде
Как уже было сказано, режимы заводских тестов призваны для того, чтобы тестировать аппаратные и программные компоненты смартфонов и планшетов. Они начинают постепенно исчезать из новых моделей различных производителей, так как становятся ненужным инструментом в связи с появлением встроенных систем тестирования и браковки гаджетов на заводе.
Не все знакомы с Factory Test Android, что это и для чего нужно. Заводские режимы для тестов могут существенно отличаться друг от друга не только на основе различий в релизе и версии операционной системы, но и в связи с требованиями к программным и аппаратным средствам конкретного производителя. Основными тестами в Factory Mode являются:
Необходимо более подробно рассмотреть каждый вид.
Для чего нужен Auto Test
Авто тест — это самый главный и общий тест, при котором будут протестированы основные функции телефона. Он по максимуму пройдется по всей аппаратной части смартфона или планшета и проверит на работоспособность все доступные модули.
Важно! Именно этот тест необходимо делать, если производится простая и общая диагностика устройства. Просто так в фабричный режим не заходят, а полное сканирование позволит проверить все доступные модули на работоспособность.
Manual Test
Аналог Full Test или Auto Test, который выполняет такую же проверку тех или иных средств и модулей гаджета, выясняя, какие из них работают корректно, а какие подлежат замене или вообще не откликаются на запрос.
Clear eMMC Android — что это
Не все знакомы и с параметром Clear Emmc Android, что это и как работает. На самом деле все очень просто. Это сброс данных (кэша и прочих настроек). Он работает аналогично стандартным функциям «Очистка кэша» и «Сброс настроек до заводских параметров», которые доступны в соответствующем разделе приложения «Настройки».
Аналог этого пункта можно найти в рекавери под названием «wipe data/factory reset». Также он может называться «Clear Flash».
Важно! Следует внимательно относиться к этой функции и не нажимать на нее. В противном случае все данные с телефона будут удалены.
Процесс загрузи Factory Mode
Что такое Debug Test
Debug Test представляет собой процесс входа в режим отладки и начало проверки на наличие ошибок с их дальнейшим исправлением. В нем можно пройтись по всем проблемам операционной системы андроид и решить их по возможности.
PCBA Test Android — что это
Еще один пункт в фабричном меню, предназначение которого заключается в калибровке датчика движения и приближения, встроенного в переднюю панель корпуса гаджета. Также он может называться «Device PCBA Calibration», но от изменения наименования суть работы не меняется. Процессор и ряд других модулей проверят датчик на работоспособность и откалибруют его в соответствии со стандартными настройками.
Check if Root or Not
Некоторые производители также добавляют в свой фактори моде специальный раздел под названием «Check if Root or Not». Из этого остановится понятно, что весь его функционал направлен на определение, есть ли на данном мобильном устройстве права и привилегии суперпользователя или нет.
Большинство платных и бесплатных программ для проверки наличия рут-прав, которые можно найти или купить в официальном магазине Google Play Market или на сторонних ресурсах, чаще всего используют уже встроенный в систему функционал и преподносят его в более приемлемом для большинства пользователей интерфейсе.
К сведению! Каким именно образом происходит проверка, будь то поиск специального файла в корневом каталоге операционной системы или запросы через встроенный терминал, знает только производитель устройства.
Очитка данных через специальный пункт «Wipe data»
Таким образом, был разобран фактори моде на андроиде, что это такое и зачем он нужен. Данный режим позволяет сделать множество тестов и проверить телефон или планшетный компьютер под управлением платформы Android на работоспособность тех или иных аппаратных и программных модулей. Также можно по аналогии с рекавери сбросить данные и настройки или проверить наличие рут-прав.
Factory Mode на Android: что это такое и как из него выйти?
В операционной системе Android есть столько всего, что когда начинаешь разбираться, глаза разбегаются. Например, знаете ли вы, что такое Recovery Mode? А это, между прочим, меню восстановления. Есть и другие режимы, например, Factory Mode. Что это такое?
Factory Mode переводится с английского как «заводской режим». По сути, это вшитая в прошивку утилита для тестирования и настройки вашего смартфона. Factory Mode состоит из нескольких основных пунктов, их может быть как 5, так и 10 в зависимости от версии вашего устройства. Иногда встречается меню всего из 3 пунктов. Вот, к примеру, Factory Mode, состоящий из 9 пунктов меню.
Вы можете заметить, что меню заводского режима в данном случае представлено на английском языке, что уже хорошо. На некоторых смартфонах это меню может быть на китайском диалекте и разобраться в нем будет куда сложнее.
Некоторые из пунктов меню:
Отчасти Factory Mode может заменить собой Recovery Mode (например, для сброса настроек), но это абсолютно разные режимы. Кроме того, на большинстве устройств Factory Mode позволяет только провести тестирование смартфона, но не даст вам выполнить других действий вроде все того же сброса настроек (Hard Reset).
Кстати, обращаем ваше внимание на то, что перемещение по Factory Mode производится с помощью механических клавиш (Power и клавиш регулировки звука), хотя где-то используются и сенсорные клавиши управления, которые находятся под экраном.
Как включить Factory Mode?
Factory Mode можно найти далеко не в каждом смартфоне. Некоторые производители от него отказались по той простой причине, что тестирование устройства проводится с помощью фирменных утилит или специальных комбинаций клавиш.
Если в вашем устройстве имеется Factory Mode, чаще всего он запускается:
Нажатием на клавишу Power и клавишу увеличения звука выключенного устройства:
При нажатии на клавишу Power и клавишу уменьшения звука выключенного устройства:
При нажатии на клавишу Power и клавиши увеличения и уменьшения звука одновременно выключенного устройства:
При этом вы можете запустить Recovery Mode или другое меню, будьте аккуратны.
Как выйти из Factory Mode?
Это очень просто. В меню Factory Mode вы можете увидеть пункт Reboot — в переводе «Перезагрузка».
Именно его вам и нужно выбрать для перезагрузки устройства. При этом смартфон будет загружен в обычном режиме. Больше вам ничего делать не нужно.
Друзья! Если наш сайт помог вам или просто понравился, вы можете помочь нам развиваться и двигаться дальше. Для этого можно:
Другие интересные статьи:
61 комментарий: Factory Mode на Android: что это такое и как из него выйти?
а если нет такого названия reboot в меню? как выйти из него?
Попробуй нажать на кнопку включения смарта и удерживай, пока не выключится. Потом просто включи и он должен загрузиться. Удачи
А если не помогает (15 сек и больше)?
держи либо дольше (минуту), либо попробуй нажать на кнопку power и кнопку звука (увеличения или уменьшения — по очереди). что-то по-любому должно сработать.
Премного благодарен! Все получилось! Удачи Вам!
Получилось одновременное нажатие кнопки включения и кнопки уменьшения громкости
Спасибо, помогли выйти из программы.
Дело в том, то что мне нужен режим «Download Mode» чтобы установить прошивку, клавиша громкости вверх у меня «Recovery» вниз «Factory Mode» Посмотрев множество обзоров по установке прошивок, клавиши «вниз» это режим «Download Mode», но он почему-то у меня не открывается…
factory mode по идее тоже загружает прошивку только через прогу на пк
я нажимаю на reboot, телефон выключается и включается, и то же самое вылазит
что делать? он терь не включается! хэлп
а как выбрать этот Reboot? на какую кнопку?
можно выбрать пункт reboot — это перезагрузка.пункты выбираются клавишами громкости, выкл, клавиша включение.Если не помогло, одновременно зажимаем 2 клавиши громкости и потом кнопку включения.через пару сек он выключится,перезагрузится в обычном режиме
Выбрала ребоот, дальше телефон ни на что не реагирует, ни выключается, ничего не меняется
А что если и это не помогает?
А если не работают кнопки звука. Можно ли по-другому выйти из него?
после clear emmc не включается телефон, что делать?
У Mеня не получилось через reboot выйти. помогите пожалуйста
У вас тут вообще не те картинки… это не фактори мод. А выйти из фактори мода (Один мод) — жмете обе громкости + меню + повер несколько секунд. Телефон ребутнется.
Спасибо тебе. Только это и помогло.
Что делать, если нажала reboot, а телефон до сих пор не включается?
Ребята каким-то чудом я вышла, он завис, я перезагрузила и все, он включился
Люди, помогите, я нажимаю Reboot, он перезапускается, но запускается не в обычном режиме, а опять заходит в Factory Mode, что мне делать? (Смартфон — BQ5022 Bond)
а как прошить если у меня только есть тесты, версия и возврат
full test
iten test
test report
version
reboot
У меня тоже так. Попробуй просто нажать кнопку включения, пока он не включится.
Это не тот мод. Тебе нужен odin. P.S. +громкость, павер и хом.
Юзер_228 Такая же история, ничего не могу сделать
Спасибо огромное!Очень помогли.Удачи вам.
Пробовала на DooGee x 20, ничего не помогло с Google аккаунтом
А что делать, если нажимаешь на Reboot, он перезагружается, но не входит в обычный режим?
Что делать, у меня ходит, как будто я нажала кнопку «+» и не отпускаю, не могу остановить и нажать на «Reboot»?
Помогите,я уже все перепробовала ничего не помогает,что делать!
Здравствуйте!
Прочитал Вашу данную статью и посмотрел видео по восстановлению контактов из смартфона (Android).. решения для моего варианта не нашёл (кроме выпаивания, что в моём случае не устраивает). Очень прошу прочитать и помочь в моей ситуации.
ПРОБЛЕМА:
У меня смартфон Prestigio PAP5503 DUO. Перестал включаться спустя год-два работы. Достался б\у (без моего аккаунта Гугл). Включаю (около 100 раз так пробовал, по началу включался на 5-10 раз, а потом вообще ни в какую), идёт загрузка анимационного логотипа и выключается, при этом не полностью, экран не чёрный, а как бы слегка чёрно-серый, типо в каком-то глюк-режиме, в котором если не вынуть батарею — сильно греется, то ли процессор, то ли батарея и я вынимаю/размыкаю батарею.
ЗАДАЧА:
1. Вынуть все данные что возможно: 1). Контакты; 2). смс; 3). Календарь; 4). Вайбер-контакты и все переписки; 5). Галерею (Фото и видео, альбом «скриншоты» и другие).
РЕШЕНИЕ:
1. Синхронизации с Гугл — нету (не мой аккаунт стоял);
2. Выпаивать схему — я бы очень не хотел прибегать к этому, (только если НИ ОДИН другой более щадящий вариант без этого не поможет).
3. Нахожусь всё ещё в надежде хоть бы раз запустить его чтобы установить какую-то программу по типу «Nokia PC Suite» чтобы вытащить контакты на ноут в таком формате (CVS) или другом, чтобы потом также просто закинуть их в другой смартфон, а первый — перепрошить или что ему там требуется. Очень верю что мой смарт ещё не полностью накрылся, т.к. только что получилось войти в спец-меню при загрузке, где 8 вариантов (на англ. яз.) что можно сделать с системой. В шапке названия написано «Factory Mode», под ним: Auto Test, Manual Test, Item Test, Test Report, Debug Test, Clear eMMC, Version, Reboot. Возможно можно как-то его перезагрузить или т.п., или найти причину не включения в этом меню… Помогите пожалуйста если можете! Заранее благодарен! С уважением, Виктор.
найти SP FlashTool, найти инструкцию, как считать с его помощью полностью память телефона. Не накосячить при этом, например не сняв галочки в тесте памяти. Получившийся файл образа скормить программе, которая найдёт на нём разделы и смонтирует их. Из соответственных разделов вытащить нужные данные.
Или обратиться к специалистам по восстановлению данных. Цена будет дороже пачки сигарет 🙂
причина невключения для этой модели стандартна: неисправна микросхема памяти. Фактори меню не поможет.
а как выбрать перезагрузку? у меня не получается
Спасибо за статью. Помогло выйти из программы.
Быстрый старт: гайд по автоматизированному тестированию для Android-разработчика. JVM
Привет! Меня зовут Сергей Иванов, я ведущий разработчик Android в Redmadrobot. С 2016 использую автотесты различных категорий и успел в этом набить немало шишек. Именно поэтому решил поделиться опытом. Возможно, что кому-то статья поможет систематизировать знания или начать применять эту практику в работе.
Автоматизированное тестирование — одна из самых сложных и холиварных тем в сфере разработки ПО. По моим наблюдениям, немногие в сообществе пишут автотесты, а те, кто это делают, не всегда получают реальную пользу. Кроме того, подступиться к теме не так-то просто: материалы в основном разрозненные, не всегда актуальны для нужной платформы, а в чем-то и противоречивы. В общем, чтобы начать нормально писать тесты, нужно очень много искать и разбираться.
В статье подсвечу основные аспекты автоматизированного тестирования, его специфику на Android, дам рекомендации для решения популярных вопросов и эффективного внедрения практики на проекте — то, к чему я сам пришел на текущий момент.
Подробнее расскажу про тесты на JVM, а не про UI-тесты, о которых в последнее время пишут часто. Материал будет хорошей отправной точкой для изучения темы, а также поможет дополнить уже имеющиеся знания.
Дисклеймер: статья получилась большой, поэтому указал основные темы, которые рассмотрю.
System Under Test (SUT) — тестируемая система. В зависимости от типа теста системой могут быть разные сущности (о них подробнее написал в разделе «категории тестов»).
Для различия уровня тестирования по использованию знаний о SUT существуют понятия:
Black box testing — тестирование SUT без знания о деталях его внутреннего устройства.
White box testing — тестирование SUT с учётом деталей его внутреннего устройства.
Выделяют также Gray box testing, комбинацию подходов, но ради упрощения он будет опущен.
Для обеспечения базового качества автотестов важно соблюдать некоторые правила написания. Роберт Мартин сформулировал в книге «Clean Code» глобальные принципы F.I.R.S.T.
Fast — тесты должны выполняться быстро.
Independent — тесты не должны зависеть друг от друга и должны иметь возможность выполняться в любом порядке.
Repeatable — тесты должны выполняться с одинаковым результатом независимо от среды выполнения.
Self-validating — тесты должны однозначно сообщать о том, успешно их прохождение или нет.
Timely — тесты должны создаваться своевременно. Unit-тесты пишутся непосредственно перед кодом продукта.
Структура теста состоит как минимум из двух логических блоков:
Проверка результата заключается в оценке:
При необходимости также добавляются блоки подготовки и сброса тестового окружения, отчасти связанные с первыми тремя принципам F.I.R.S.T.
Подготовка окружения заключается в создании SUT, установке исходных данных, состояний, поведения и др., необходимых для имитации ситуации, которую будет проверять тест.
На этапе сброса окружения может осуществляться очистка среды после выполнения теста для экономии ресурсов и исключения влияния одного теста на другой.
Зачастую для настройки окружения применяются тестовые дублеры.
Test doubles (Тестовые дублёры) — фиктивные объекты, заменяющие реальные объекты, от которых зависит SUT, для достижения целей теста.
Тестовые дублеры позволяют:
Самая популярная классификация включает 5 видов тестовых дублеров, различных по своим свойствам: Dummy, Fake, Stub, Spy, Mock.
Stub — объект, который при вызовах его функций или свойств возвращает предустановленные (hardcoded) результаты, а не выполняет код реального объекта. Если же функция не имеет возвращаемого значения, то вызов просто игнорируется.
Mock — объект, позволяющий проверять поведение SUT путём отслеживания обращений к функциям и свойствам объекта: были ли в ходе теста вызваны функции мока, в правильном ли порядке, ожидаемые ли аргументы были в них переданы и т.д. Может также включать функциональность Stub.
Почитать об этих и остальных видах дублеров можно в первоисточнике.
Эта классификация не является стандартом, и в фреймворках для создания тестовых дублёров часто ради удобства API несколько типов обобщают термином Mock. А вот чем они на самом деле будут являться, зависит от их последующей конфигурации и применения в тесте. Например, при использовании фреймворка Mockito, экземпляр тестового дублера может быть создан как Dummy, а потом превращен в Stub и в Mock.
При именовании созданных с помощью фреймворка дублеров уместно использовать именования, продиктованные фреймворком. Вообще, в мировом сообществе многие оперируют термином Mock и вне кода, подразумевая на самом деле дублёры разных типов. Бывает, что это путает. Но, в большинстве случаев в тестах используются стабы, а вовсе не моки.
В русскоязычной среде встречается мнение, что разница между Stub-ом и Mock-ом заключается в том, что первый — это дублер, написанный вручную, а второй — созданный с помощью специального фреймворка. Но это заблуждение.
Различия полезно знать, чтобы не путаться в общении с коллегами, когда в контексте обсуждения тип дублера важен.
Есть разные версии категоризации тестов, по разным характеристикам, поэтому существует некоторая путаница.
Покажу основные категории уровней тестов, на которых тестируется система, на примере одного из самых распространенных вариантов пирамиды тестирования:
Unit-тесты проверяют корректность работы отдельного unit-а (модуля). Unit-ом (то есть SUT данного типа тестирования) может быть класс, функция или совокупность классов.
Integration-тесты (в приложении) проверяют корректность взаимодействия модулей или наборов этих модулей (компонентов). Определение SUT данной категории является еще более расплывчатым, т.к. в свою очередь зависит от того, что считается модулем.
Грань между Unit- и Integration-тестированием довольно тонкая. Интеграционными тестами, в зависимости от масштаба и контекста, в принципе могут называть тесты, проверяющие взаимодействие чего-либо с чем-либо с определенной долей абстракции: приложение(клиент)-сервер, приложение-приложение, приложение-ОС и др. Но в дальнейшем я буду говорить об интеграционном тестировании в рамках приложения.
End-to-end-тесты (E2E) — интеграционные тесты, которые воздействуют на приложение и проверяют результат его работы через самый высокоуровневый интерфейс (UI), то есть на уровне пользователя. Использование тестовых дублеров на этом уровне исключено, а значит обязательно используются именно реальные сервер, БД и т.д.
Кстати, визуализация автоматизированных тестов в виде пирамиды говорит о том, что тесты более низкого уровня — основа более высокоуровневых, а также о рекомендуемом количественном соотношении тестов того или иного уровня в проекте.
Вернёмся к категориям. В Android сложность категоризации автотестов усугубляется еще и тем, что они могут работать на JVM или в Instrumentation-среде (эмулятор или реальное устройство). Последние называют инструментальными.
Чтобы было удобнее ориентироваться в видах тестов, не путаясь в терминологии, предлагаю такую категоризацию для мобильного приложения на Android:
JVM Integration tests — интеграционные тесты, проверяющие взаимодействие модулей или совокупностей модулей без использования Instrumentation. Характеризуются они высокой скоростью исполнения, сравнимой с Unit-тестами, также выполняющимися на JVM.
Instrumentation Integration non-UI tests — интеграционные тесты, исполняемые уже в реальной Android-среде, но без UI.
Component UI tests — интеграционные инструментальные тесты с использованием UI и фиктивных сервера и БД, если таковые требуются. Тест может состоять как из одного экрана, запущенного в изоляции, так и из нескольких экранов с соблюдением их реального флоу.
E2E UI tests — интеграционные инструментальные UI-тесты без тестовых дублеров только с реальным флоу экранов. Максимально приближены к ручным тестам.
Если Unit-тесты являются сильно завязанными на детали реализации, очень быстро выполняются, относительно легко пишутся и наиболее точно при поломке указывают на причину ошибки, то в случае E2E UI ситуация противоположная. Изменение этих характеристик происходит постепенно от низа к верху пирамиды.
При переходе от тестов на JVM к тестам на Instrumentation из-за использования настоящей Android-среды происходит резкое падение скорости выполнения этих тестов. Это становится серьезным ограничением. Особенно когда тесты необходимо запускать часто и много раз подряд. Поэтому к написанию инструментальных тестов следует прибегать лишь в случаях, когда использование настоящих Android-зависимостей действительно необходимо.
Несмотря на малую зависимость от низкоуровневых деталей реализации SUT, UI-тесты являются самыми хрупкими. Вызвано это их зависимостью от самого UI. Изменение разметки, реализации отображения, анимации и т.д. могут потребовать длительных манипуляций для обеспечения работоспособности теста.
Часто они оказываются нестабильны в своём поведении и могут то выполняться, то падать, даже если не вносилось никаких изменений в реализацию (нестабильные тесты называют Flaky). Мало того, UI-тесты могут совершенно по-разному себя вести на разных устройствах, эмуляторах и версиях Android. Когда же UI-тесты являются еще и E2E, добавляется хрупкость и снижается скорость выполнения из-за реальных внешних зависимостей. Причем в случае ошибки найти её причину бывает затруднительно, поскольку проверки в таких тестах осуществляются на уровне состояния UI. В таких ситуациях выгоднее обойтись силами QA-инженеров.
Конечно, UI-тесты способны приносить и весьма существенную пользу. Мобильные приложения имеют свойство разрастаться, и в какой-то момент их ручное регрессионное тестирование выходит за адекватные временные рамки. Тогда часть проверок может быть делегирована E2E UI-тестам, что при удачном исполнении может здорово сократить время тестирования.
Поэтому, для написания UI-тестов желательно иметь разработчиков или QA-инженеров-автоматизаторов, которые будут заниматься именно ими бÓльшую часть времени.
Unit-тесты тоже в определенной мере хрупкие, но уже из-за того, что они больше связаны с деталями реализации, которым свойственно периодически меняться. При сильном изменении реализации SUT и связанных с нею сущностей может потребоваться почти полностью переписать unit-тест. Но unit-тесты стабильны.
Степень хрупкости же можно снизить за счет использования black box-стиля написания даже на этом уровне, когда возможно. Но не следует злоупотреблять применением тестовых дублеров: если уже реализованная сущность имеет тривиальную логику или наличие логики не подразумевается, стоит использовать ее настоящую реализацию.
А заменять дублером следует только то, что действительно необходимо для приемлемой изоляции SUT в конкретном случае. Иногда (но далеко не всегда!) бывает оптимальнее сделать переиспользуемый рукописный дублер, чем конфигурировать его фреймворком для создания дублеров в множестве мест.
Хочу отметить, что какими бы хорошими не были автотесты, полностью отказываться от ручного тестирования нельзя. Человеческий глаз и смекалка пока что незаменимы.
Дальше я буду говорить преимущественно о тестах на JVM. Но некоторые моменты актуальны и для остальных категорий.
Раньше для написания JVM-тестов наши разработчики использовали фреймворки Junit 4 и Junit 5, но потом переключились на молодой перспективный Spek 2. Junit 4 нужен для инструментальных тестов — с другими фреймворками они не работают.
Для проверок (assert) используем AssertJ — отличную библиотеку с богатым набором читабельных ассертов и удобных дополнительных функций.
Для создания тестовых дублеров применяем Mockito-Kotlin 2 — Mockito 2, адаптированный для Kotlin.
Для стаббинга и мокирования сервера — MockWebServer — библиотеку от Square, рассчитанную на работу с OkHttp.
Фреймворки PowerMock и Robolectric не используем из соображений скорости выполнения тестов и их надёжности. Кроме того, эти фреймворки поощряют «плохо пахнущий код» — это дополнительные зависимости, без которых вполне можно обойтись. Для этого код должен быть тестируемым.
Признаки нетестируемого кода:
Следовать принципам SOLID, использовать слоистую архитектуру. Грамотное разделение и реализация сущностей позволит писать изолированные тесты именно на интересующую часть функционала, не допускать чрезмерного разрастания тестового файла и, при необходимости, осуществлять распараллеливание разработки. DI позволит подменять настоящие реализации тестовыми дублёрами.
Стремиться к чистоте функций. Это функции, которые:
Пример теста такой функции:
Минимизировать количество Android-зависимостей. Часто прямое использование Android-зависимостей в SUT не является необходимым. Тогда их следует выносить вовне, оперируя в SUT типами, поддерживающимися на JVM.
Самая распространенная Android-зависимость в потенциально тестируемых классах — ресурсы, и их выносить из, скажем, ViewModel, ну, совсем не хочется. В таком случае можно внедрить Resources во ViewModel, чтобы стаббить конкретные ресурсы (их id актуальны на JVM) и проверять конкретные значения:
Но лучше поместить Resources во Wrapper, предоставляющий только необходимый функционал работы с ресурсами, и сделать его тестовую реализацию. Это избавит SUT от прямой зависимости от фреймворка и упростит подготовку окружения в тестах:
При таком поведении TestResourceProvider по умолчанию правильность строки в ожидаемом результате можно сверять по id ресурса:
В общем случае лучше вообще не заменять дублерами типы, принадлежащие сторонним библиотекам и фреймворкам. Это может привести к проблемам при обновлении их API. Обезопасить себя можно также с помощью Wrapper. Подробнее ситуация разобрана в статье “Don’t Mock Types You Don’t Own”.
Использовать Wrapper-ы для статических функций, управления асинхронным и многопоточным поведением. Существует немало стандартных статических функций или Android-зависимостей в виде таких функций. Если нужно иметь с ними дело, то следует помещать их во Wrapper-ы и внедрять в SUT для последующей подмены.
Это поможет и при работе с асинхронностью и многопоточностью: инкапсулирующий управление ими Wrapper можно заменить тестовым дублером, который позволит проверяемому коду выполняться в одном потоке и синхронно вызвать асинхронный код. Для RxJava и Kotlin Coroutines есть стандартные решения от их авторов.
Важно оформлять тесты качественно. Иначе они помогут в момент написания, но в будущем будет уходить много времени на их понимание и поддержку.
Например, при падении теста, который сложно сходу понять и исправить, есть шанс, что его пометят как «игнорируемый» или удалят. Особенно если таких тестов много, ведь они тормозят продолжение разработки. Вот старый пример не самого удачного теста из опенсорса:
Чтобы достичь желаемого эффекта от тестов, необходимо уделить внимание качеству их дизайна.
Чтобы сделать содержимое теста более читабельным, его следует разделять на блоки соответствующих этапов. Я выбрал BDD-стиль, где есть этапы:
Пример разделения тела теста:
«Лицо» теста — его название. Оно должно быть читабельным и ёмко передавать информацию о содержимом, чтобы для ориентации не приходилось каждый раз анализировать это самое содержимое.
В тестах на JVM Kotlin позволяет использовать пробел и дефис при обрамлении названия функции обратными кавычками. Это здорово повышает читабельность. В инструментальных тестах это не работает, поэтому текст пишется в CamelCase, а вместо дефисов используются нижние подчеркивания.
Для тестов на Junit применим следующий паттерн именования в простых случаях:
В более сложных случаях, когда есть дополнительные условия:
Так имя теста написано в виде требования, и в случае падения будет сразу видно, какой сценарий отработал некорректно:
Фреймворк Spek 2 выводит всё это на новый уровень. Он предоставляет «из коробки» DSL в стиле Gherkin (BDD).
Блоки Given, When, Then — подтесты глобального теста, описанного с помощью блока Scenario. Теперь нет необходимости ставить всё описание в названии, можно просто расположить все части в соответствующих блоках.
Результат выполнения имеет иерархический вид:
Эти блоки могут присутствовать внутри Scenario в любом количестве, а для придания еще более «человекочитаемого» вида можно использовать блок And. Теперь насыщенный сценарий можно оформить, не растянув при этом название теста далеко за границу экрана:
Благодаря блокам типа Feature можно удобно разделять тесты для разных фич, если в одном тестовом файле их несколько.
Чтобы добиться схожего разделения и отображения результатов с помощью Junit 5, понадобилось бы написать в тестах много бойлерплейта с аннотациями.
Чтобы сделать содержимое тестов читабельнее, нужно следовать нескольким правилам:
1. Если проверки результатов выполнения одного действия над SUT тесно связаны, допустимо иметь несколько проверок в тесте. В противном случае это должны быть отдельные тесты. Основная проблема в том, что если в тесте несколько проверок и одна из них фейлится, то последующие проверки осуществлены не будут.
В Spek 2 вместо создания полностью отдельных тестов, если они концептуально относятся к одному сценарию, разделение проверок можно сделать с помощью блоков Then/And внутри Scenario:
В Junit 4 такой возможности нет. На помощь приходит механизм SoftAssertions из AssertJ, который гарантирует выполнение всех assert в тесте. Например:
2. Если проверки объемные, нежелательные к разделению и повторяющиеся, следует выносить их в отдельную функцию с говорящим названием.
3. Использовать обобщающие конструкции тестового фреймворка для одинаковой настройки окружения, если настройка повторяется для большого количества тестов, находящихся на одном уровне иерархии (например, beforeEachScenario и afterEachScenario в случае Spek 2). Если настройка одинакова для нескольких тестовых файлов, можно использовать Extension для Junit 5, Rule для Junit 4, а для Spek 2 подобного механизма «из коробки» нет, поэтому нужно обходиться конструкциями before…/after….
4. Объемные схожие настройки тестового окружения следует также выносить в отдельную функцию.
5. Использовать статические импорты для повсеместно применяемых функций вроде функций проверок AssertJ и Mockito.
6. Если создание вспомогательных объектов объемное, используется в разных тестовых файлах и с разными параметрами, следует завести генератор с дефолтными значениями:
Очень важно не переборщить с созданием вспомогательных функций и архитектурных изысков, поскольку KISS и единообразие в автотестах важнее, чем DRY. Когда все тесты в проекте написаны однотипно и прозрачно, они гораздо лучше воспринимаются.
Когда предыдущие пункты соблюдены, тесты уже можно применять как документацию, свернув тестовые функции в IDE.
Для сворачивания и разворачивания всех блоков кода в файле в случае Mac используются комбинации клавиш “Shift” + “⌘” + “-” и “Shift” + “⌘” + “+”, для управления конкретным блоком — “⌘” + “-” и “⌘” + “+” соответственно.
В тестах на Junit 4 можно сделать еще лучше, сгруппировав тесты по регионам, ведь их тоже можно сворачивать.
В тестах на Spek 2 нет нужды делать разделение тестов по регионам, поскольку их можно хорошо сгруппировать с помощью блоков Scenario и Feature.
Если в файле с тестами присутствуют некоторые вспомогательные свойства или функции, их также стоит поместить в регион. Это поспособствует улучшению фокусировки внимания на названиях тестовых функций.
Так тесты сформированы в виде последовательных требований к SUT, в которых удобно ориентироваться. Теперь они отличная документация для ваших коллег и вас самих, которая поможет быстро разобраться или вспомнить, что делает SUT.
Она лучше обычной текстовой, поскольку в отличие от тестов, обычную документацию можно забыть актуализировать. Чем тесты более высокоуровневые, тем более близкими к составленным аналитиком функциональным требованиям будут их названия. Это будет заметно в разделе «JVM Integration Testing».
Если нужно протестировать корректность работы SUT с разнообразным набором входных данных, но при этом основная реализация тестов меняться не должна, можно использовать параметрический тест.
Он может быть запущен много раз, каждый раз принимая разные аргументы. Поэтому отпадает надобность писать множество одинаковых тестов, у которых отличаются только входные данные и ожидаемый результат. Достаточно написать один тест и указать набор данных, которые будут поочередно в него передаваться. Часто параметрические тесты оказываются подходящим выбором для тестирования валидаторов, форматтеров, конвертеров и т.д.
В документации Spek 2 не написано о возможности написания параметрических тестов, хотя она есть, и писать их проще, чем в Junit 4 и Junit 5. Для этих целей удобно использовать стиль тестов Specification.
Я писал, что степень хрупкости unit-тестов при изменениях исходного кода, обусловленную их привязкой к деталям реализации модуля, можно снизить. Это применимо для всех non-UI тестов.
Написание тестов в стиле White box искушает расширять видимость функций/свойств SUT для проверок или установки состояний. Это простой путь, который влечет за собой не только увеличение хрупкости тестов, но и нарушение инкапсуляции SUT.
Избежать этого помогут правила. Можно сказать, что взаимодействие с SUT будет в стиле Black box.
Существует аннотация-маркер @VisibleForTesting для выделения функций/свойств, модификатор доступа которых расширили для тестирования. Благодаря этому маркеру Lint подскажет разработчику, обратившемуся к функции/свойству в таком месте исходного кода, в котором они на самом деле не должны быть доступны, что видимость функции расширена только для тестирования. Несмотря на возможность использования такого маркера, прибегать к расширению видимости всё равно не рекомендуется.
Лучше избегать прямого управления асинхронным и многопоточным поведением в SUT. Для тестирования же кода, использующего RxJava или Coroutines, применяются специфичные решения. Сейчас в большинстве наших проектов используется RxJava, поэтому расскажу именно про нее.
Для тестирования SUT, осуществляющей планирование Rx-операций, нужно произвести замену реализаций Scheduler-ов так, чтобы весь код выполнялся в одном потоке. Также важно иметь в виду, что на JVM нельзя использовать AndroidSchedulers.mainThread().
В большинстве случаев все Scheduler-ы достаточно заменить на Schedulers.trampoline(). В случаях, когда нужен больший контроль над временем события, лучше использовать io.reactivex.schedulers.TestScheduler с его функциями triggerActions(), advanceTimeBy(), advanceTimeTo().
Замену реализаций можно совершить двумя способами:
Первый способ — официальный и может быть применен независимо от того, как спроектирована SUT. Он имеет не самое удачное API и неприятные нюансы работы, усложняющие применение в некоторых ситуациях (например, когда внутри тестового файла в одних тестах нужно использовать Schedulers.trampoline(), а в других — TestScheduler).
Суть подхода Schedulers Injection заключается в следующем: экземпляры Scheduler-ов попадают в SUT через конструктор, благодаря чему в тесте они могут быть заменены на иные реализации. Этот подход является очень прозрачным и гибким. Также он останется неизменным независимо от выбранного тестового фреймворка (Junit 4, Junit 5, Spek 2…) — чего нельзя сказать об RxPlugins, которыми придется в каждом управлять по-своему.
Из минусов Shedulers Injection можно выделить необходимость внедрения дополнительного аргумента в SUT и необходимость использования вместо rx-операторов с Sheduler по умолчанию (таких как delay()) их перегруженные варианты с явным указанием Scheduler.
Есть две неплохие статьи на тему обоих подходов: раз, два. Но там упомянуты не все нюансы RxPlugins.
Я предпочитаю второй подход. Чтобы упростить внедрение и подмену реализаций в тесте, я написал SchedulersProvider:
Его применение в коде:
А вот и его тестовая реализация с Scheduler-ами по умолчанию, вместо которых при надобности можно передать TestScheduler:
Применение в тесте:
Вообще, RxJava «из коробки» имеет и другие полезные инструменты для тестирования (TestObserver, TestSubscriber), но они не входят в рамки статьи.
JVM Integration-тесты проверяют взаимодействие модулей или совокупностей модулей на JVM. Какие именно связки стоит тестировать, зависит от конкретных случаев.
В самых масштабных тестах этого типа проверяется взаимодействие всей цепочки модулей от ViewModel до Http-клиента, поскольку в этом промежутке обычно располагается основная логика, требующая проверки. Обеспечивать работу View на JVM обычно накладно и не имеет большого смысла.
Тест взаимодействует с SUT через ViewModel, инициируя действия и проверяя результат.
Чтобы достичь максимальной степени проверки SUT в данном случае следует заменять тестовыми реализациями только те сущности, которые действительно в этом нуждаются. Типичный набор таких сущностей:
Соответствующие функции достаточно вызывать перед первым и после последнего теста в тестовом файле. Пример применения в Spek 2:
Персистентные хранилища данных (SharedPreferences, Room и т.д.)
Базовая логика управления тестовым сетевым окружением сконцентрирована в классе BaseTestNetworkEnvironment. Он используется на JVM и в Instrumentation. За специфическую конфигурацию под каждую из сред отвечают его классы-наследники: JvmTestNetworkEnvironment и InstrumentationTestNetworkEnvironment.
Сервер запускается при создании экземпляра *NetworkEnvironment до запуска теста и отключается функцией shutdownServer() после завершения теста (в случае Gherkin-стиля Spek 2 — до и после Scenario соответственно).
Для удобной настройки ответов на конкретные запросы используется функция dispatchResponses. При необходимости к mockServer можно обратиться напрямую.
Содержимое JvmTestNetworkEnvironment уже сильно зависит от специфики конкретного проекта, но цель его неизменна — заменить некоторые сущности локального сетевого окружения тестовыми дублерами, чтобы код работал на JVM.
Функции для упрощения создания серверных ответов:
Тела фиктивных серверных ответов сгруппированы по object-ам, соответствующим разным запросам. Это делает тестовые файлы чище и позволяет переиспользовать ответы и значения их полей в разных тестах. Одни и те же ответы используются тестами на JVM и Instrumentation (в том числе UI).
После добавления комментария «language=JSON» IDE подсвечивает синтаксис JSON. Подробнее о Language injections можно почитать тут.
С помощью выноса значений интересующих полей ответов в константы, можно использовать их при проверках в тестах, не дублируя строки. Например, убедиться, что описание ошибки из серверного ответа корректно передано в Snackbar. Тело ответа получается посредством вызова функции с параметрами, которые при надобности позволяют конфигурировать ответ из теста.
Схожим образом вынесены и пути запросов:
Общие для JVM и Instrumentation файлы должны находиться в директории, доступной обоим окружениям. Доступ настраивается в build.gradle:
Взаимодействие View и ViewModel построено особым способом, благодаря которому очень удобно писать unit-тесты ViewModel и integration-тесты. Публичные функции ViewModel представляют события со стороны View (обычно они соответствуют действиям со стороны пользователя) и именуются в событийном стиле:
ViewModel воздействует на View посредством двух LiveData:
Этот подход в более удобном виде реализован в нашей библиотеке.
Пример организации ViewModel, ViewState и ViewEvents:
Наконец, пример JVM Integration-теста:
Так тестируется основная логика пользовательских сценариев. Эти сценарии с теми же данными затем могут быть проверены в UI-тестах.
Не нужно тестировать чужие библиотеки — это ответственность разработчиков библиотек (исследовательское тестирование — исключение). Тестировать нужно свой код.
Unit-тесты следует писать на логику, в которой есть реальная вероятность совершения ошибки. Это могут быть ViewModel, Interactor, Repository, функции форматирования (денег, дат и т.д.) и другие стандартные и нестандартные сущности. Тривиальную логику тестировать не стоит. Но нужно следить за изменением непокрытой тестами логики, если она при очередном изменении перестанет быть тривиальной, то тогда её нужно протестировать.
100%-е покрытие кода тестами несёт с собой вред: трата лишнего времени на написание бесполезных тестов, боль при изменении реализации, при поддержке бесполезных тестов, иллюзия хорошо протестированной системы. Процент покрытия не отражает реальной картины того, насколько хорошо система протестирована.
Я предпочитаю не устанавливать минимальный порог тестового покрытия для нового кода. Однако для разработчика всё же может быть полезной точечная проверка покрытия SUT, над которой он работает.
Тестами нужно проверять не только основные сценарии, но и краевые. Обычно там кроется наибольшее число багов.
При исправлении бага в коде, который не покрыт тестами, следует его ими покрыть.
JVM Integration-тесты от ViewModel до слоя данных следует писать для каждого экрана. Менее масштабные JVM Integration — при надобности. Возможны случаи, когда большинство модулей, включая ViewModel, сами по себе являются слишком простыми, чтобы их стоило покрывать unit-тестами. Однако создание масштабного JVM integration-теста на всю цепочку будет очень кстати, тем более что пишутся такие тесты достаточно просто и однотипно.
Нужно стараться не проверять в тестах более высокоуровневых категорий то, что проверено в более низкоуровневых, но повторы проверок основных сценариев во всё большей интеграции — это нормально.
Тесты Instrumentation Integration non-UI — только когда нужно проверить что-то, что нельзя адекватно проверить на JVM.
E2E UI- и Component UI-тесты нужны для замены части ручных тестов при регрессионном тестировании. Разумно доверить их написание QA-инженерам. В настоящее время мы с коллегами ищем оптимальный подход к тому, как организовывать UI-тесты, в каком количестве их писать и как сочетать с более низкоуровневыми тестами.
Можно подумать, что о написании тестов уже известно достаточно и пора идти в бой, но есть еще один момент… Вы, вероятно, собрались написать очередную фичу и затем покрыть её тестами? Замечательная идея. Именно так и стоит делать, пока навык написания тестов не будет более менее отработан. Такой подход называют Test Last. Конечно же, среди пишущих тесты разработчиков он наиболее распространен. Но он имеет серьезные недостатки:
Решить эти проблемы можно, используя принцип Test First, придуманным Кентом Беком. Он основан на идее: «Never write a single line of code unless you have a failing automated test» (не стоит писать код реализации, пока для него не написан падающий тест).
На базе этого принципа Кент Бек создал методологию Test Driven Development (TDD, разработка через тестирование). Согласно ей, разработка должна вестись итеративно, путем цикличного повторения шагов Red-Green-Refactor (микро-цикл):
Подразумевается, что в итерации падающий тест должен быть только один.
Позже Роберт Мартин развил TDD, сформулировав Three Laws of TDD (нано-цикл):
Из-за второго правила работа сводится к поочерёдному написанию строчки реализации SUT за строчкой теста. Нано-циклы заставляют фокусироваться на очень маленькой подзадаче. Это также помогает, когда не знаешь, с чего начать реализацию.
Со временем Робертом были сформулированы еще два более масштабных цикла. Про всех них можно почитать в его статье.
Технику применения нано-циклов я использую далеко не всегда. Частые перескакивания в сложной задаче приводят к потере фокуса и снижают продуктивность. Несмотря на то, что более крупные циклы должны помогать этого избегать. Считаю, что эту технику лучше применять точечно и комфортный размер шага следует выбирать каждому самостоятельно. Жесткое следование всем правилам на практике не всегда идёт на пользу, но полезно при обучении.
Я несколько отступился от канонов и нашел эффективным такой алгоритм работы при реализации новой фичи:
1. Вникнуть в задачу, спроектировать связи между модулями, определить их ответственность.
2. Создать SUT, описать его интерфейс.
3. Создать тестовый файл для SUT, объявить тесты-требования.
4. Реализовать тест(ы)
5. Реализовать SUT, чтобы реализованные тесты успешно выполнились.
6. Отрефакторить SUT, сохранив успешность выполнения реализованных тестов.
7. Если остались нереализованные тесты, перейти к пункту #4.
Алгоритм доработки SUT, которая уже покрыта тестами:
Но если к началу работы над задачей невозможно получить достаточного представления о том, какие будут модули, их ответственность и связи, и для формирования представления требуется начать писать реализацию, экспериментировать, то TDD применять не стоит. В противном случае может быть потеряно много времени на переписывание тестов.
Приступаем к реализации по принципу Test Last, но как только достаточное представление сформируется, делаем паузу и переходим к тестам, продолжая дальнейшую разработку уже по TDD. Незачем также применять TDD для реализации тривиальной логики, если вы не собираетесь покрывать её тестами.
По итогу получаем от подхода следующие преимущества:
TDD — это в первую очередь подход к разработке. Методология замечательно показывает себя при реализации SUT с unit- и JVM integration-тестами, поскольку их можно быстро и часто запускать. С Instrumentation non-UI-тестами применять её можно, но из-за длительности запуска придется запускать тесты реже. Применять же TDD с UI-тестами крайне не рекомендуется.
Порог входа в TDD высок. Сперва следует закрепить базовые навыки написания тестов. Применять методологию в повседневности или нет — личное дело каждого, но не стоит отказываться, не попробовав. На моей практике встречались фичи со столь сложной логикой, требования к которой много раз менялись, что благополучную реализацию этих фич без TDD я себе не представляю.
Применение автоматизированного тестирования способно вывести разработку ПО на качественно новый уровень. Главное — подходить к делу осознанно.
Разработчикам рекомендуется делать акцент на написании тестов на JVM. Чтобы поддержка тестов и изменения в кодовой базе не становились болью, следует писать только те тесты, которые действительно представляют ценность. Важно внимательно отнестись к дизайну продуктового и тестового кода, соблюдать ряд правил, стандартизировать подходы среди всех разработчиков проекта.
Можно извлекать существенную пользу за счет применения TDD с тестами на JVM. Применять его следует не всегда. Разработчику нужно самостоятельно подобрать комфортный размер шага в цикле разработки по TDD.
