Да, как указывал в статье, тоже предпочитаю интеграционные тесты UI тестам.
По поводу мокирования сервера - есть много способов. Мы искали наиболее универсальный подход, который можно было бы переиспользовать для других платформ - например iOS (KMM в этом очень сильно помог) и к тому же который было бы довольно просто обновлять и следить за тем, чтобы он соответствовал поведению настоящего сервера, и без больших дополнительных затрат позволял прогонять тесты при изменении сервера. Как упомянул - этого можно достичь с помощью контрактных тестов. О которых также планирую написать статью
Спасибо за замечание! В данном случае локализация скорее всего никак не повлияет. Основная функция `LINE_EXTRA_SPACE` в данном случае – постараться предотвратить перенос строки из-за разницы в ширине символов. Поскольку шрифт может быть не моноширинный, и в случае если мы удаляем скажем символ `a` и добавляем на его место `щ` - может произойти перенос строки. но если же мы уже удалим `aб` и добавим `щ` то переноса строки уже не будет.
Можно конечно попробовать точнее пройти в цикле и по одному удалять символы пока точно не найдем нужную ширину. Но, как указа в статье - это усложнит код, и можем повлиять на производительность
Спасибо за наводку! Пока не смотрел. Проект использует немного устаревшую версию Compose (так как версия Compose завязана на версию Kotlin). К сожалению самые новые подходы пока не применить и приходится искать решения исходя из того что есть.
Если будет большой интерес к этой теме, и соберется достаточно материала для статьи, то вероятно напишу пост также на эту тему. Но как вы точно заметили, сейчас многие моменты упростились и порой помещаются в один комментарий или ответ на форуме.
Хорошее замечание! С асинхронный кодом всегда следует быть особенно внимательным, и там есть достаточно много особенностей.
На данный момент пока не планирую статей про особенности таких тестов. В этих вопросах зачастую много особенностей выбранной технологии. (Rx, Classic threads, Kotlin Coroutines, свои проприетарные решения).
Согласен, в случае использования mockito, создавать моки можно с помощью аннотации. Я предпочитаю запись вида val locationRepository: LocationRepository = mock(),потому что в этом случае можно использовать val вместо var, ну и зачастую так получается 1 строка вместо 2.
По поводу coverage, есть несколько интересных моментов, которые хотелось бы рассмотреть. В любом случае, за качеством тестов следует следить, и coverage одна из метрик, но и с ней следует быть осторожным, высокое покрытие не гарантирует высокое качество тестов, хотя вот высокого качество тестов вряд ли удастся достичь без высокого покрытия.
По этой причине статья относится к категории `Обзор`, также изначально она включала в себя блок про unit тесты, но с примерами, объем получился слишком большим. Поэтому решил разделить на 2 отдельных статьи.
А можно узнать мнение/рекомендацию автора, как бы он поступил с описанным в статье примером в ситуации: Single Activity (активити живет дольше чем каждый из компонентов), SingleChatScreen и SettingsChatScreen — это фрагменты, которые занимают весь экран. Когда создавать тот или иной компонент и когда занулять его ссылки?
Спасибо
Спасибо за замечание, но, пожалуй, ключевая фраза —
С моей точки зрения
По поводу того, чем является MVP — архитектурой или лишь паттерном presentation-слоя сломано много копий, я придерживаюсь 2 трактовки. Согласен, приведенная мной формулировка не самая удачная. Но под пользовательским интерфейсом подразумевается не только тот интерфейс, который представлен на экране пользователя смартфона, а интерфейс в более широком понимании — канал, по которому пользователь взаимодействует с приложением, все возможные способы получения информации от него и передачи ему
В нашем проекте используется самописный MVP. ЖЦ обрабатываем так, что разделяем данные, которые относятся к бизнес-логике и к состоянию UI. Данные бизнес-логики хранятся в репозиториях, которые имеют свой ЖЦ и не зависят от экранов. А данные относящиеся к состоянию UI сохраняем в бандлах и в некоторых специфичных случаях в retain фрагментах.
Спасибо за конструктиврную критику, будем учитывать в нашей работе. Однако дизайн-гайды платформ постоянно развиваются и меняются. После прошедшего Google I/O как раз произошли большие перемены в плане дизайна, а удобство — это отчасти дело привычки, которая, возможно, еще не успела сформироваться
Да, как указывал в статье, тоже предпочитаю интеграционные тесты UI тестам.
По поводу мокирования сервера - есть много способов. Мы искали наиболее универсальный подход, который можно было бы переиспользовать для других платформ - например iOS (KMM в этом очень сильно помог) и к тому же который было бы довольно просто обновлять и следить за тем, чтобы он соответствовал поведению настоящего сервера, и без больших дополнительных затрат позволял прогонять тесты при изменении сервера. Как упомянул - этого можно достичь с помощью контрактных тестов. О которых также планирую написать статью
Спасибо за замечание! В данном случае локализация скорее всего никак не повлияет. Основная функция `LINE_EXTRA_SPACE` в данном случае – постараться предотвратить перенос строки из-за разницы в ширине символов. Поскольку шрифт может быть не моноширинный, и в случае если мы удаляем скажем символ `a` и добавляем на его место `щ` - может произойти перенос строки. но если же мы уже удалим `aб` и добавим `щ` то переноса строки уже не будет.
Можно конечно попробовать точнее пройти в цикле и по одному удалять символы пока точно не найдем нужную ширину. Но, как указа в статье - это усложнит код, и можем повлиять на производительность
Спасибо за наводку! Пока не смотрел. Проект использует немного устаревшую версию Compose (так как версия Compose завязана на версию Kotlin). К сожалению самые новые подходы пока не применить и приходится искать решения исходя из того что есть.
Если найду более изящные способы - дополню статью
Если будет большой интерес к этой теме, и соберется достаточно материала для статьи, то вероятно напишу пост также на эту тему. Но как вы точно заметили, сейчас многие моменты упростились и порой помещаются в один комментарий или ответ на форуме.
Хорошее замечание! С асинхронный кодом всегда следует быть особенно внимательным, и там есть достаточно много особенностей.
На данный момент пока не планирую статей про особенности таких тестов. В этих вопросах зачастую много особенностей выбранной технологии. (Rx, Classic threads, Kotlin Coroutines, свои проприетарные решения).
Согласен, в случае использования mockito, создавать моки можно с помощью аннотации. Я предпочитаю запись вида
val locationRepository: LocationRepository = mock(),потому что в этом случае можно использовать val вместо var, ну и зачастую так получается 1 строка вместо 2.По поводу coverage, есть несколько интересных моментов, которые хотелось бы рассмотреть. В любом случае, за качеством тестов следует следить, и coverage одна из метрик, но и с ней следует быть осторожным, высокое покрытие не гарантирует высокое качество тестов, хотя вот высокого качество тестов вряд ли удастся достичь без высокого покрытия.
Спасибо за обратную связь!
По этой причине статья относится к категории `Обзор`, также изначально она включала в себя блок про unit тесты, но с примерами, объем получился слишком большим. Поэтому решил разделить на 2 отдельных статьи.
Спасибо