Comments 15
Интересная статья. Но немного разочаровал итог с тем как это тестировать. Смешано все в одно, хотя вытеснение фоновых процессов и DKA вызывают разное поведение системы и приложения, а их совместное включение может вызвать и третье.
Все таки DKA это про активити, а вытеснение фоновых, команда в adb и kill process в логкате это уже про процесс (и по мне это три пути к одному результату)
Привет, спасибо)
Есть dka - вытеснение фоновых activity, и есть лимит фоновых процессов, второе я не упоминал в статье.
Про остальное да, это про процессы, но которые влияют на жц активити. Собственно ниже написал, что в контексте активити всё же лучше использовать dka. Рассматривал именно, что будут вызываться те же события жц, так как мы тестируем код за это отвечающий.
То что между ними есть разница вроде тоже написал)
Возможно не стоило, действительно, остальное писать, но хотелось охватить разные инструменты, которые можно использовать.
а ещё возможно как-то непрозрачно получилось "как это тестировать" относится именно к убийству процесса системой, а не ко всей статье
Я к тому что DKA и kill process в логкате (он же adb shell am kill/ограничение фоновых процессов) это разное и если стоит задача проверить поведение про восстановление активити, то это DKA, а если запуск после убийства процесса системой это второе и нельзя с помощью первой фичи проверить второе, а с помощью второй первое. А блок как это тестировать говорит мол бери любой способ
Я тебя понял,
Я переписал, дополнил этот пункт, надеюсь стало лучше. Четче отметил разницу и отметил, что можно проверять тем и другим способом.
Только отмечу, что если цель проверить механизм сохранения/восстановления activity, то убийство процесса, когда приложение в фоне, также приводит к вызову того же кода, так что тут сильных противоречий не вижу.
Наверное даже, если посмотреть, то тестирование с kill предпочтительнее, так как это более реальный сценарий в системе.
очень хорошая статья, спасибо. Подобные статьи с глубоким погружением в логику работы ОС очень редки и оттого ценны. Когда сам начал заниматься мобильным тестированием, то столкнулся с массой чек-листов по особенностям тестирования мобилок где было много сомнительных проверок, без технического обоснования их необходимости. Это же было (а может и есть) на некотоых популярных курсах. Начал копать эту тему и оказалось, что большинство из проверок на самом деле не нужны. Это касается всяких там "проверьте, что при получении смс ваше приложение не легло".
Интересно кроме dka, многими другими методами пользуются активно? Казалось, что dka достаточно было во всех тех продуктах, в которых работал.
Да обычно в рамках стандартных сценариев тестирования достаточно dka, к убийствам процесса приходится прибегать чаще, когда пытаешься воспроизвести сложный баг и с dka он не воспроизводится.
Я помню ещё в начале карьеры был у меня такой баг, с dka не воспроизводился, а когда система сама убивала приложение воспроизводится. Вот бы мне тогда рассказали про эти команды и как они работают и различия между dka и убийством системой, а то приходилось для воспроизведения буквально запускать программы, чтобы они вытеснили моё приложение(
3 раза прочитал статью и все равно не понимаю зачем и какие кейсы проверять при dont keep activity
Привет, краткий ответ написан в заключении. Вы проверяте, что ваше приложение корректно сохраняет экран приложения и восстанавливает его - это введённые пользователем данные, открытые попапы, может точка скролла (зависит от бизнес требований) и т.д. всё что нужно сохранить, проверяете, что данные не пропадают и нет крашей.
Если прямо пример: вы ввели очень много текста в мессенджере, вы хотите найти подходящий мем, чтобы прикрепить к сообщению, заходите в браузер, скачивайте и возвращайтесь в мессенджер, а всё, что вы ввели стёрлось. Потому что система убила процесс приложения, а приложение не сохранило корректно своё состояние.
вот чтобы не прыгать по приложениям и гадать когда же система его убъёт, чтобы протестить эти сценарии, нужно использовать dka.
Тут выше комменты, что dka не полностью эмулирует убийство процесса, однако, для целей тестирования схранения-восстановления состояния этого достаточно
Еще один момент хотелось бы отметить, на мой взгляд он важен: сохранение состояния активити после ее убийства системой - это не сценарий по умолчанию, а ситуация, которую должен создать разработчик ручками (вызвать метод сохранения состояния), то есть сохранения может и не происходить и это не будет багом. На нашем проекте это не предусмотрено и на холодную запускается главный экран.
Ну почти, да, методы вызываются автоматически, разработчик может не переопределить их и не обрабатывать сценарий сохранения-восстановления.
Но это не очень хорошая практика, такое возможно имеет смысл в играх, где проще с нуля запуститься, но если это обычное приложение, то это, скажем, не самый лучший для пользователя сценарий.
И можно так потерять пользователя, если он часто будет терять место, где он был, а на слабых девайсах убийство процесса довольно частое явление. Да и смена конфигурации не редкость.
Возможно стоит обсудить дополнительно необходимость обработки этих сценариев с продут овнером/менеджером. Если разработчик не захотел это делать ещё не значит, что он прав.
Когда ваше приложение умирает – жизненный цикл activity в Android для QA