Создание объектов в модульных тестах Java

aNew().car().
  with(mock(Engine.class)).
  with(fake().radio().fm_only()).
  with(aNew().powerWindows()).build();


The (contrived) example demonstrates 4 difference concepts:

• Автомобиль может быть легко построен с помощью двигателя
• Автомобиль может быть легко построен с поддельным радио FM
• Автомобиль может быть легко построен с бетонной реализацией стеклоподъемников
• Все остальные зависимости будут разумными значениями по умолчанию

Оригинальная запись Ната на эту тему гласит, что у каждого строителя должны быть «разумные значения по умолчанию». Это оставляло вещи немного открытыми для интерпретации, поэтому мы пробовали разные значения по умолчанию. В конце концов, было наиболее разумно, чтобы все разработчики тестовых данных использовали другие сборщики тестов в качестве значений по умолчанию или null. Мы никогда не используем тестовые значения в качестве значений по умолчанию. На практике это, в любом случае, не является болезненным, поскольку вы можете легко добавить свой собственный макет или подделку в конкретный тест, который требует этого.

Со строителями легко работать, потому что вы знаете, что зависимости по умолчанию являются конкретными, вместо того, чтобы смотреть на код, чтобы определить, являются ли зависимости конкретными, фиктивными или фальшивыми. Это соглашение делает написание и изменение тестов намного быстрее.

Возможно, вы также заметили методы aNew () и fake () из предыдущего примера. Метод aNew () возвращает класс DomainObjectBuilder, а метод fake () возвращает класс Faker. Эти методы являются вспомогательными, которые могут быть импортированы статически. Реализации этих классов очень просты. Учитывая объект домена Radio, DomainObjectBuilder будет иметь метод, определенный как в примере ниже.

public RadioBuilder radio() {
  RadioBuilder.create();
}

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

Следующий код показывает, как все эти вещи работают вместе.

// RadioTest.java
public class RadioTest {
    public void shouldBeOn() {
        Radio radio = aNew().radio().build();
        radio.turnOn();
        assertTrue(true, radio.isOn());
    }
    // .. other tests...
}

// DomainObjectBuilder.java
public class DomainObjectBuilder {
    public static DomainObjectBuilder aNew() {
        return new DomainObjectBuilder();
    }

    public RadioBuilder radio() {
        return RadioBuilder.create();
    }
}

// RadioBuilder.java
public class RadioBuilder {
    private int buttons;
    private CDPlayer cdPlayer;
    private MP3Player mp3Player;

    public static RadioBuilder create() {
        return new RadioBuilder(4,
            CDPlayerBuilder.create().build(),
            MP3PlayerBuilder.create().build());
    }

    public RadioBuilder(int buttons, CDPlayer cdPlayer, MP3Player mp3Player) {
        this.buttons = buttons;
        this.cdPlayer = cdPlayer;
        this.mp3Player = mp3Player;
    }

    public RadioBuilder withButtons(int buttons) {
        return new RadioBuilder(buttons, cdPlayer, mp3Player);
    }

    public RadioBuilder with(CDPlayer cdPlayer) {
        return new RadioBuilder(buttons, cdPlayer, mp3Player);
    }

    public RadioBuilder with(MP3Player mp3Player) {
        return new RadioBuilder(buttons, cdPlayer, mp3Player);
    }

    public Radio build() {
        return new Radio(buttons, cdPlayer, mp3Player);
    }
}

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

Поскольку Java дает мне перегрузку методов на основе типов, я всегда называю свои методы «с», когда могу (как показано в примере). Это не всегда работает, если, например, у вас есть два разных свойства одного типа. Обычно это происходит со встроенными типами, и в этих случаях я создаю такие методы, как withButtons, withUpperLimit или withLowerLimit.

Еще одна привычка, с которой я столкнулся, — это использование Builders для создания всех объектов в моих тестах, даже тестируемого класса. Это приводит к более ремонтопригодным тестам. Если вы явно используете конструктор Class Under Test в своем тесте и добавляете зависимость, вам в конечном итоге придется изменять каждую строку, которая создает экземпляр Class Under Test. Однако если вы используете компоновщик, вам может не потребоваться что-либо менять, и если вам придется что-то менять, это, вероятно, будет только для подмножества тестов.

Вывод

Я большой поклонник Test Data Builders и Test Doubles. Объединение этих двух концепций позволило быстрее писать тесты и легче их обслуживать. Эти идеи также могут быть добавлены постепенно, что является хорошим бонусом для тех, кто хочет добавить этот стиль в существующую кодовую базу.