Модульное тестирование композитных методов обслуживания - PullRequest
Новая
       9

Модульное тестирование композитных методов обслуживания

4 голосов
/ 24 марта 2011

Я пишу (junit) модульные тесты для класса, который реализует открытый интерфейс с такими методами, как: 

public Set<Setting> getUserSettings();

public Set<Setting> getOrganizationSettings();

public Set<Setting> getDefaults();

public Set<Setting> getAllSettings();

Методы получения настроек из определенного слоя выполняют ввод-вывод из разных мест для получения их результатов.,getAllSettings () Возвращает один набор всех настроек на всех уровнях, причем предпочтение имеет «самый верхний» уровень (т. е. если настройка существует на уровне по умолчанию и на уровне пользователя, будет использоваться настройка на уровне пользователя.

Я уже написал модульные тесты для getUserSettings (), getOrganizationSettings (), getDefaults (), макетирования операций ввода-вывода с объектами Mocked.

Реализация для getAllSettings () выглядит примерно так: 

public Set<Setting> getAllSettings(){
    Set<Setting> defaults = getUserSettings();
    Set<Setting> custom = getOrganizationSettings();
    Set<Setting> undefined = getDefaults();
    //perform some sorting and business logic
    //return fully sorted set

}

Мой вопрос заключается в том, как выполнить модульное тестирование метода getAllSettings (). Использую ли я mocks (используя easymock / powermock) для всех последующих вызовов ресурсов, которые используют методы user / organization / defaultSettings?как если бы был более чистый / лучший / простой способ сделать это.

1 Ответ

5 голосов
/ 24 марта 2011

Вы можете написать тест в следующей форме 

@Test
public void testGetAllSettings() {
   Foo fixture = new Foo() {
       public Set<Setting> getUserSettings() { // canned impl }
       public Set<Setting> getOrganizationSettings() { // canned impl }
       public Set<Setting> getDefaults() { // canned impl }
   }

   Assert.assertEquals(whatEverItShouldEqual, fixture.getAllSettings());
}

Это позволит вам проверить логику получения всех настроек независимо от других методов.

Другой альтернативой было бы посмеяться над вводом-выводом этих методов. Если у вас есть слой, который выполняет логику ввода-вывода, то это может быть посмешищем. Как вы упоминаете, это может быть неприятно, если у вас много зависимостей. Возможно, признак того, что вам нужно меньше зависимостей? (может быть, класс должен быть разбит на более мелкие единицы, например?)

...