Stanislav Bashkyrtsevgmugarновый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,

Ну вот ты открыл метод который до этого был private или package private (если мы его таки открывали для тестирования). Что здесь принципиально поменялось? Т.е. если этот метод лежал в старом классе, то тебе не нравилось его открывать только для тестирования. А если его перенести в другой класс и сделать public, то так открывать код чисто для тестирования - правильно. Почему?
gmugarон не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом формате

Плохо тут то что у нас +1 публичная сущность. До этого я видел с какими классами в пакете мне нужно было взаимодействовать, а теперь оказывается есть public классы которые на самом деле мне не нужны. Но эта проблема решается - твой новый класс можно сам по себе сделать package private, т.е. он не будет виден из-вне пакета. Но опять же - в чем разница метод открывать или класс?

мы с вами по кругу ходим.
напомню, что изначально вопрос был в том нужно ли тестировать private методы.
речь шла о private, а не о package-private, что не одно и то же.
моя мысль в том, что если, вдруг, без тестирования через private не получается (с соблюдением концепции хорошего unit-теста, одна из важных особенностей которого - простота написание этого самого unit-теста), то надо что-то менять, а не лезть в private.

Stanislav BashkyrtsevА правильный "не лезть в private" заключается в том чтоб оставить prod код в покое и тестировать все через настоящий public API (а не сконструированный только потому что тестам надо было). Со всеми вытекающими плюсами и минусами.

с этим, собственно, никто и не спорит.
вообще тестировать нужно только, этот самый, "настоящий public API".

но вот c "логику очень часть неудобно покрывать через public интерфейс."(это ваши слова), я не согласен в корне.
мой опыт, однозначно, не совпадает с этой точкой зрения.