Ну так Вы рассматриваете простой REST-клиент, для него, естественно, нет нужды брать MVP/VIPER/CA и тестировать бизнес-логику, которой (почти) нет. Но давайте рассмотрим другое приложение, для какого-нибудь интернет-магазина со своими плюшками (стандартный кейс, по мотивам реального приложения).
Берем экран «Корзина», в нем отображается список всех товаров, у каждого своя цена, скидка (для разных клиентов может быть разная), количество (его можно изменить), товар можно удалить. Тут же есть специальные подарки по акциям, у них все аналогично, только сущность другая (и работать с этими данными надо отдельно). Также на экране отображается общая цена и общая скидка, есть другие данные, есть возможность применить купон на доп скидку.
Если бы это был простой REST-клиент, то проблем нет. Но заказчик еще требует, чтобы приложение работало оффлайн. И тут возникает необходимость 1) хранить все данные в приложении, 2) отправлять это данные на сервер, 3) подсчитывать самому всю корзину и все скидки при оффлайн-работе, 3) как-то синхронизировать локальную и серверную корзину и все сопутствующие данные (делать это нужно сначала локально, а потом еще и отправлять серверу и как-то обрабатывать ошибки от сервера) и т.д. Вот тут-то ваша «копеечная бизнес логика» перерастает в огромнейший пласт логики, которую надо протестировать (иначе не оберетесь проблем с заказчиком и с пользователями, которые видели в корзине одну цену и одну скидку, а в итоговом заказе они другие).
Не забывайте, что это все нужно еще и красиво показывать (дизайнера приложения никто не отменял). А значит и отображение, и бизнес-логика по своим объемам значительны (и это все для одного лишь экрана), и их обоих нужно тестировать.
Попробуйте реализовать данный кейс в качестве примера на Вашей архитектуре, и Вы поймете, для чего были придуманы MVP/VIPER/CA.
Ну так Вы рассматриваете простой REST-клиент, для него, естественно, нет нужды брать MVP/VIPER/CA и тестировать бизнес-логику, которой (почти) нет. Но давайте рассмотрим другое приложение, для какого-нибудь интернет-магазина со своими плюшками (стандартный кейс, по мотивам реального приложения).
Берем экран «Корзина», в нем отображается список всех товаров, у каждого своя цена, скидка (для разных клиентов может быть разная), количество (его можно изменить), товар можно удалить. Тут же есть специальные подарки по акциям, у них все аналогично, только сущность другая (и работать с этими данными надо отдельно). Также на экране отображается общая цена и общая скидка, есть другие данные, есть возможность применить купон на доп скидку.
Если бы это был простой REST-клиент, то проблем нет. Но заказчик еще требует, чтобы приложение работало оффлайн. И тут возникает необходимость 1) хранить все данные в приложении, 2) отправлять это данные на сервер, 3) подсчитывать самому всю корзину и все скидки при оффлайн-работе, 3) как-то синхронизировать локальную и серверную корзину и все сопутствующие данные (делать это нужно сначала локально, а потом еще и отправлять серверу и как-то обрабатывать ошибки от сервера) и т.д. Вот тут-то ваша «копеечная бизнес логика» перерастает в огромнейший пласт логики, которую надо протестировать (иначе не оберетесь проблем с заказчиком и с пользователями, которые видели в корзине одну цену и одну скидку, а в итоговом заказе они другие).
Не забывайте, что это все нужно еще и красиво показывать (дизайнера приложения никто не отменял). А значит и отображение, и бизнес-логика по своим объемам значительны (и это все для одного лишь экрана), и их обоих нужно тестировать.
Попробуйте реализовать данный кейс в качестве примера на Вашей архитектуре, и Вы поймете, для чего были придуманы MVP/VIPER/CA.