а мне кажется это норм тех процесс.  Мне часто удобно, увидеть логи тестировщика, чем его нескладное объяснение того что он сделал и почему то что-то поломалось

и  гарантия есть только на тостер, и то на 2 месяца

нормальный тех процесс возможен с нормальным тех заданием, в котором прописаны требования. А у Вас нет 2 и 3, и приходится городить на ходу (это не нормальный тех процесс, а обычная практика)

пишите логи не слушайте ни кого, это нормальная практика на серьезных проектах

я не сомневаюсь в том, что получать логи от тестирования это удобно, остается вопрос в том, нужно ли безнес логику логировать.  Ответ думаю кроется в том, что если логи собирать на презентейшен слое, то мы будем имееть более абстрактые логи, а хочется конретики, знать после какой строчки алгоритма, появились неожиданные результаты.   Опять же тесты позволяют закрыть это, но логи значительно дешевле, логи это инструмент дебаггинга, а тесты инструмент для недопущения регресса кода

понятное дело что это крайний подход и лучше решать проблемы без этого
лучше покрывать тестами все что возможно

ну как я выше написал, тесты дороже и является след этапом проверки кода, после более абстрактого лога, тем более что логирование в релизной сборке всегда можно выключить

так то да, но когда у Вас будет печататься логи после каждой строки - они будут чрезмерно подробные, и Вы будете тратить время на поиках внутри логов

А что Вы вообще ищите в логах у тесторов? краши?

а для этого есть фильтр, он может быть кастомный и вообще я эти логи могу не печатать в консоль, а лишь отсылать на сервак с id конретного тестировщика и номером сессии

Ещё есть такая хорошая штука как удалённые логи. Приходит от пользователя запрос в поддержку, и можно посмотреть, как у него там что работало в приложении, что ошибка случилась. Никогда вы не сделаете настолько идеального приложения и тестов, что у юзеров ничего не будет падать, и иметь отладочную информацию очень полезно.
Только это всё уже не архитектура, а оффтоп. Архитектуры тут ровно одна строчка - нужны логи в домене - делайте интерфейс Logger и вызывайте, делов-то) Мы, например, юзаем Timber везде, включая домен, он достаточно платформонезависим и удобен. Можно и обычные логи писать, и нефатальные исключения логировать в крашлитику.

все верно

да пока что ничего, в коде есть всего один лог, когда доставка завершена и ее запросто можно в презентейшен модуль вынести и возможно в рамках текущего проекта логирование бизнеса излишне ибо это не супер сложный бизнес с кучей алгоритмов.  Я про случай с сложной бизнес логикой, ну вот типо калькулятор какой-то, там есть что смотреть в логах бизнеса.

ну и понял в итоге, что все зависит от нужд проекта

в андроиде чаще всего это излишне, ну пока так кажется, можности мобилок тоже растут и бизнес прибавляется

спасибо всем большое!

У нас вообще логируется каждый action и вся цепочка изменений стейта связанных с этим action, все это в реалтайме отправляется на сервер. когда пользователь обращается с проблемой или ошибкой - консультант открывает базу логов и легко может отследить какие действия пользователя и как изменили стейт фичи, и из-за чего возникла ошибка. очень удобно для поддержки я считаю

по 1 запросу или пачкой?

оказывается многие так делают, не только мы)

по одному запросу на каждое изменение стейта