Как тестировать закрытые методы класса?

Question

[KaminskyIlya]

Есть некий класс, и работа его публичных методов основана на работе закрытых вспомогательных методов. Ну пусть такой:

public class PersonDate
{
public PersonDate(Date birthday) { ... }

public int getYearsOld() 
{
  return isValid() ? getYear( getNextBirthdayDate() ) - getYear( getBornDate() ) + 1 : 0; 
}
// (TODO: нужен тест) возвращает год для даты
private static int getYear( Date date ) { ... }
// (TODO: нужен тест) возвращает дату следующего дня рождения
private Date getNextBirthdayDate() { ... }

Нужно убедиться, что закрытые вспомогательные функции getYear() и getNextBirthdayDate() правильно отрабатывают. Собственно, как протестировать их работу в JUnit или любом другом подобном фреймворке ?

Можно, конечно, сказать, что модульное тестирование (по фен-шую) не предполагает знание о внутреннем устройстве тестируемого класса, и органичиться тестированием только внешних методов (рассматривая класс чисто как черный ящик). Однако оставим в стороне "идеологические войны" и сконцентрируемся на поставленной задаче. Я вижу следующие способы решения вопроса.

1. Способ первый.
Метод getYear() объявлен статическим. Его можно вынести в публичный вспомогательный класс, либо внутренний, либо внешний:

static final class DateUtils
{
public static int getYear( Date date ) { ... }
}

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

2. Способ второй.
Объявить тестируемый метод с уровнем доступа package. Это сработает, т.к. тестирующий класс компилируется с тестируемым в одном и том же пакете. Но изменять область видимости только ради написания теста... хм...

3. Способ третий. Давно забытое старое.
Написать тестирующий класс внутри тестируемого:

public class PersonDate
{
...
public static class PersonDateTest
{
    @Test
    public testGetNextBirthDate()
    {
    }
}

В этом случае тестирующий класс получает полный доступ ко всем закрытым полям объекта-владельца.
Но вроде как, подобный подход - уже не по мейнстриму? Кажется ранее (до JUnit и подобных фреймворков), именно такая методика написания тестов и была основной. Внутренние тестовые классы при компиляции превращаются в отдельные файлы вида PersonDate$PersonDateTest.class и затем легко могут быть удалены из продакшн средствами сборки.

Коллеги, может быть кто знает другие более красивые способы?
Или какие-то фреймворки предоставляют подобный функционал?

Буду благодарен за все ваши ответы.

Answer 1

[Артем]

Коллеги, может быть кто знает другие более красивые способы?

- через рефлекшен! Если же у Вас есть возможность изменить область видимости, то тогда не стоит его использовать. Если такой возможности нет, то вот Вам паттерн:

Method method = PersonDate.class.getDeclaredMethod("getYear", Int.class);
        method.setAccessible(true);
        method.invoke(targetObject, argObjects);

Comments

[KaminskyIlya]

Премного благодарствую! Я совсем запамятовал о такой возможности.
Кажется, таким же образом можно устанавливать поля закрытых переменных класса (если для них нет публичных сеттеров).

[Артем]

KaminskyIlya: Да, совершенно верно!