Как лучше всего тестировать конструктор (или сеттеры) с помощью JUnit?

Question

У меня есть два решения для проверки моего конструктора (или сеттеров).

Первое - использовать getters.

public void Test() {
    Person p = new Person("toto"); // name
    assertEquals("toto", p.getName());
}

Второе - использовать Field класс

public void Test() {
    Person p = new Person("toto"); // name
    final Field fieldName = p.getClass().getDeclaredField("name");
    fieldName.setAccessible(true);
    assertEquals("toto", fieldName.get(p));
}

Какая ваша рекомендация и почему? Спасибо.

Answer 1

ИМО, следует избегать отражения везде, где это возможно . Конечно, есть ситуации, когда это необходимо, но в большинстве случаев это не стоит больших компромиссов с производительностью и безопасностью.

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

Рассмотрим следующий пример:

public class Message {
    private String message;

    public Message(Message message) {
        this.message = message;
    }

//  NO GETTERS/SETTERS
}

Если бы я хотел проверить, что этот конструктор "работает", я мог бы написать тест, который использует отражение, чтобы заглянуть внутрь моего объекта и проверить, соответствует ли сообщение параметру конструктора. Но что в этом хорошего?

Предположительно, я хочу, чтобы этот класс сообщений каким-то образом использовался другим фрагментом кода. Как работает этот код? Я обнаружу, что мне, вероятно, нужен метод getMessage() или что-то эквивалентное, чтобы сделать что-нибудь полезное с объектом.

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

Кроме того, я бы не стал перегружать тесты такими «тривиальными», как этот. Сосредоточьтесь на тестировании вашей бизнес логики c. Доверьтесь, что JVM в основном работает так, как рекламируется.

Answer 2

Вы можете использовать очень удобную библиотеку openpojo для автоматического тестирования POJO.

https://github.com/OpenPojo/openpojo