А потом уже этот класс тестировать роболектриком? Идея в том, что в конечном счёте всё равно придётся где-то работать с контекстом для строк.

ну да, придется, моя идея тут скорее, в том чтобы вынести в принципе формирование таких сложных сообщений из презентера, даже если вы их просто из строк складываете, без контекста.

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

А как же кисс? Ну или точней не делать заранее то, что может и не понадобиться?

Давайте обратимся к истокам. Щас вот наброшу прям =)
А почему именно нельзя иметь контект в презентере или бизнес-логике? В чем обоснование?
Я слышал такие причины, что нельзя тогда простестить. Но есть Роболектрик, пожалуйста.
Роболектрик долгий. У меня он стартует за 6 секунд, это много?
На сколько я знаю, если Роболектрик стартовал для одного теста, то уже просто подрубается к следующим. То есть 6 секунд тратится один раз. Дальше все по накатке.
Действительно иногда требуется либо получение строки, либо даты, либо еще чего-то.
Не спорю, можно это обходить энамом, врапперами и т.д. Но стоит ли это того?
Я придерживаюсь позиции, что архитектура должна нам прежде всего помогать, а не усложнять. А если следовать бездумно некоторым  канонам, смысл которых не так ясен, мне кажется не совсем верным.

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

Ага, случай для кисс, вот если они сразу нужны в другом презентере, тогда можно и выносить, а пока не нужны, нафига)

имхо тестирование вообще мимо. Смысл в разделении приложения по слоям. И вот уже исходя их этого контекста не должно быть в презентере.

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

Ну канон один "разделяй код и властвуй", иначе он будет властвовать над тобой)

Только может не стоит усложнять? Делая то, без чего можно обойтись в данный момент или всегда стоит думать, о том, что вдруг надо будет сделать еще много много чего?

смотря что вы имеете ввиду, продумывать наверное стоит наперед, но в рамках разумного конечно, все не предусмотришь

Как контекст влияет на разделение по слоям?
Мне кажется, это вообще про разное

Контекст - эти доступ к ресурсам

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

Если код более менее нормальный, то вынести это потом, при необходимости, не должно быть сложным.

а в том, что дата слой никакого отношения к контексту не должен иметь. Но это все мастурбация непонятно на что. Если единственная порблема кода это контекст в презентере, то это хороштй код)

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

Презентер это не дата слой, а ui слой.

Ну так то да, но лишняя работа, особенно, если это в одном методе презентера.