Azure-sdk-for-java: Использование моков в модульных тестах

Моки в модульных тестах

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

Моки предоставляют удобный механизм для обхода взаимодействия с методами, выходящими за рамки ваших модульных тестов. Это позволит вам сосредоточиться на тестировании кода, который входит в область ваших модульных тестов, и не беспокоиться о внешних классах / библиотеках / зависимостях.

При этом код должен быть тестируемым без использования каких-либо имитирующих библиотек, таких как Mockito, JMockit и т. Д. «Подделки, а не Mocks». Поддельный объект - это просто замена реального объекта. В то время как реальный объект может иметь реальную бизнес-логику, поддельный объект может просто возвращать стандартные ответы.

public interface ConfigurationService {
        Configuration readConfiguration(String configurationName);
}

public class AzureConfigurationService implements ConfigurationService {
    Configuration readConfiguration(String configurationName) {
        // read configuration from Azure configuration service
    }
}

public class MyApplication {
    private final ConfigurationService configurationService;
    public MyApplication(ConfigurationService configurationService) {
        this.configurationService = configurationService;
    }

    public String getConfigurationOwner () {
        Configuration configuration = configurationService.readConfiguration("configName");
        return configuration.getOwner();
    }
}


public class Test {
    <strong i="10">@Test</strong>
    public void testMyApplication() {
        // unit test won't work as it requires connection to azure services
        MyApplication myApplication = new MyApplication(new AzureConfigurationService()); 
        assertEquals("foo", myApplication.getConfigurationOwner());
    }
}

Вместо этого вы можете ввести поддельную зависимость

public class FakeConfigurationService implements ConfigurationService {
    public Configuration readConfiguration(String configurationName) {
        Configuration configuration = new Configuration();
        configuration.setOwner("foo");
        return configuration;
    }
}

public class Test {
    <strong i="14">@Test</strong>
    public void testMyApplication() {
        // unit test will now work as the fake object requires no network connection
        MyApplication myApplication = new MyApplication(new FakeConfigurationService());
        assertEquals("foo", myApplication.getConfigurationOwner());
    }
}

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

Хорошие кандидаты на использование макета:

1. Зависимости, требующие сетевого подключения - Любые зависимости, передаваемые по сети, такие как доступ к базе данных, вызовы служб REST и т. Д.
2. Файловая система - методы / классы, требующие файловых операций. К этому следует относиться так же, как к зависимости, требующей сетевого подключения. Рассмотрим случай, когда файл может находиться в NFS .
3. Классы сторонних библиотек - поиздевайтесь над ними с умом . Ваш код зависит от этих библиотек, и лучше не имитировать их, если только они не являются библиотеками, которые внутренне используют файловые или сетевые операции. В идеале такие библиотеки должны быть заключены в собственный интерфейс, а зависимость должна содержаться.
4. Тесты даты и времени - тесты, которые полагаются на дату, можно смоделировать, чтобы вернуть даты в будущем / прошлом. Некоторые функции требуют выполнения через определенные промежутки времени. Внедрение фиктивного объекта часов с тикерами, которые могут имитировать 100 тактов часов за секунду, полезно вместо того, чтобы позволять модульному тесту запускаться в течение 100 секунд.

Не смейся

Статические методы - библиотеки, такие как PowerMock, позволяют имитировать статические методы, но за это приходится платить. Он вмешивается в загрузчик классов по умолчанию и может привести к несогласованному поведению в тестах и ​​рабочей среде выполнения. Кроме того, некоторые из этих библиотек мешают инструментарию покрытия тестами и приводят к неверным отчетам о тестовом покрытии.

Решение : если вам нужно имитировать статический метод, сначала оцените, есть ли способ реорганизовать ваш код и устранить необходимость в статическом методе. Если это невозможно, подумайте о том, чтобы изолировать доступ к статическому методу, заключив его в метод, который можно легко смоделировать.

public class ClassToTest {
    public String methodToTest() {
        String retVal = Util.notTestFriendlyStaticMethod();
        return process(retVal);
    }
}

Подумайте о том, чтобы сделать

public class ClassToTest {
    private UtilWrapper utilWrapper;

    public ClassToTest(UtilWrapper utilWrapper) {
        this.utilWrapper = utilWrapper;
    }

    public String methodToTest() {
        String retVal = utilWrapper.callStaticUtilMethod();
        return process(retVal);
    }
}

public class Test {
    <strong i="10">@Test</strong>
    public void testMethod() {
        UtilWrapper utilWrapper = Mockito.mock(UtilWrapper.class);
        when(utilWrapper.callStaticUtilMethod()).thenReturn("ExpectedString");
        ClassToTest classToTest = new ClassToTest(utilWrapper);
        assertEquals("expectedstring", classToTest.methodToTest());
    }
}

Издевательство над финальными классами

Если вы используете Mockito, требуется дополнительная настройка, чтобы иметь возможность имитировать классы final как описано в документации Mockito 2 .

Обратите внимание, что большинство (если не все) клиентские классы, представленные в пакете SDK для Azure, - это final . Эти клиенты используют сеть для связи со службами Azure.

Как потребитель клиентских библиотек Azure SDK, ваше приложение зависит от сторонней библиотеки, которая выполняет сетевые вызовы. В таких сценариях для вашего приложения рекомендуется абстрагироваться от зависимости и скрывать ее за своим собственным интерфейсом. Это будет содержать область зависимости только в рамках реализации интерфейса, и ваше приложение будет использовать только интерфейс, который вы определили. Это позволяет вашему приложению переключаться между различными реализациями интерфейса без необходимости вносить изменения в ваше приложение. Дополнительным преимуществом является то, что теперь ваши модульные тесты могут либо использовать поддельную реализацию, как показано в примере вверху этой страницы, либо использовать макет, не требуя специальной конфигурации, чтобы включить имитацию классов final .