В Guava есть аннотация VisibleForTesting. Её описание из кода библиотеки:

Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.

То есть предполагается, что этой аннотацией мы будем отмечать методы и поля, которые, по идее, должны были быть private, но для тестов были сделаны package-private или public.

По поводу этой аннотации я хотел бы сказать, что она, ИМХО, не нужна.

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

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

До:

@VisibleForTesting
static final double AVOGADROS_NUMBER = 6.02214199e23;
@VisibleForTesting
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
@VisibleForTesting
static final double ELECTRON_MASS = 9.10938188e-31;

После:

static final double AVOGADROS_NUMBER = 6.02214199e23;
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
static final double ELECTRON_MASS = 9.10938188e-31;

И ещё. Описание к аннотации намекает, что некоторые члены могут быть не только раскрыты, но и созданы исключительно для тестирования. Так вот, я не Кент Бек, конечно, но вроде бы:

1. продакшн код не должен испытывать никаких структурных изменений, сделанных исключительно для тестирования;

2. если некоторый класс ну никак не протестировать без введения туда новых членов, то скорее всего беда с качеством кода. За подробностями можно обратиться к «Чистому коду».

А ещё я иногда вижу такое:

/* package */ class SomeClass implements SomeInterface  {

Для кого этот комментарий вообще?

Несогласные призываются в комменты.

Статья Мартина Фаулера Public versus Published Interfaces. В целом ничего очень нового или исключительно интересного, но заставила задуматься, почему различие public-published на уровне языка реализовано далеко не во всех языках.

Суть:

Публичный интерфейс, public interface — методы класса, которые могут быть использованы любыми другими объектами.

Опубликованный интерфейс, published interface — то, чем пользуются внешние клиенты нашей, например, библиотеки. Они вызывают методы и наследуются своими классами.

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

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

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