Mockito Mock vs. Spy в весенних загрузочных тестах

Я встречал многих разработчиков, которые называют тесты «модульными тестами», когда они на самом деле являются интеграционными тестами. В сервисных слоях я видел тесты, называемые модульными тестами, но написанные с зависимостями от реального сервиса, такого как база данных, веб-сервис или некоторый сервер сообщений. Это часть интеграционного тестирования. Даже если вы просто используете Spring Context для автоматической привязки зависимостей, ваш тест является интеграционным тестом. Вместо использования реальных сервисов вы можете использовать макеты и шпионы Mockito, чтобы поддерживать свои тестовые юнит-тесты и избежать накладных расходов на проведение интеграционных тестов.

Это не значит, что интеграционные тесты плохие. Конечно, есть роль для интеграционных тестов. Они необходимы.

Но по сравнению с модульными тестами интеграционные тесты являются sloooowwwww. Очень медленно. Ваш типовой юнит-тест будет выполнен за доли секунды. Даже сложные модульные тесты на устаревшем оборудовании будут завершаться за доли секунды.

Интеграционные тесты, с другой стороны. занять несколько секунд, чтобы выполнить. Для запуска Spring Context требуется время. Требуется время, чтобы запустить базу данных H2 в памяти. Требуется время, чтобы установить соединение с базой данных.

Хотя это может показаться незначительным, оно становится экспоненциальным в большом проекте. Когда вы добавляете все больше и больше тестов, длина вашей сборки становится все длиннее и длиннее.

Ни один разработчик не хочет нарушать сборку. Поэтому мы проводим все тесты, чтобы быть уверенными. При кодировании мы будем запускать полный набор тестов несколько раз в день. Для вашей собственной производительности набор тестов должен выполняться быстро.

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

При недавнем взаимодействии с клиентами команда разработчиков очень усердно работала над написанием тестов. И это хорошо. Но команда предпочла написание интеграционных тестов. Часто интеграционные тесты использовались там, где можно было использовать модульное тестирование. Сборка становилась все медленнее и медленнее. По этой причине команда начала рефакторинг своих тестов для использования имитаторов и шпионов Mockito, чтобы избежать необходимости в интеграционных тестах.

Они по-прежнему тестировали те же цели, но Mockito использовался для заполнения зависимости, обусловливая необходимость проведения интеграционного теста.

Например, Spring Boot упрощает тестирование с использованием базы данных H2 в памяти, используя JPA и репозитории, поставляемые Spring Data JPA.

Но почему бы не использовать Mockito для создания макета для репозитория Spring Data JPA?

Модульные тесты должны быть атомными, легкими, быстрыми и проводиться в виде отдельных блоков. Кроме того, модульные тесты в Spring не должны вызывать Spring Context. Я писал о различных типах тестов в моем предыдущем посте « Программное обеспечение для тестирования» .

Я уже написал серию постов о JUnit и пост о тестировании Spring MVC с Spring Boot 1.4: часть 1 . В последнем я рассмотрел модульное тестирование контроллеров в приложении Spring MVC.

Я считаю, что большинство ваших тестов должны быть модульными, а не интеграционными. Если вы пишете свой код в соответствии с принципами SOLID ООП , ваш код уже хорошо структурирован, чтобы принимать макеты Mockito.

В этой статье я объясню, как использовать Mockito для тестирования сервисного уровня приложения Spring Boot MVC. Если Mockito является новым для вас, я советую сначала прочитать мою публикацию Mocking in Unit Tests With Mockito .

Мокито издевается против шпионов

В модульном тесте двойной тест — это замена зависимого компонента (соавтора) тестируемого объекта. Двойник теста не должен вести себя точно так же, как соавтор. Цель состоит в том, чтобы имитировать соавтора, чтобы заставить тестируемый объект думать, что он действительно использует соавтора.

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

Есть несколько других типов тестовых двойников, таких как фиктивные объекты, поддельные объекты и заглушки. Если вы используете Спока, одним из моих любимых приемов было составить карту замыканий в качестве тестового двойника. (Одна из многих забавных вещей, которые вы можете сделать с Groovy!)

Что делает фиктивный объект отличным от других, так это то, что он имеет проверку поведения. Это означает, что фиктивный объект проверяет, что он (фиктивный объект) правильно используется тестируемым объектом. Если проверка прошла успешно, вы можете сделать вывод, что тестируемый объект будет правильно использовать настоящий соавтор.

Шпионы, с другой стороны, предоставляют способ шпионить за реальным объектом. С помощью шпиона вы можете вызывать все реальные базовые методы объекта, все еще отслеживая каждое взаимодействие, так же, как если бы вы имитировали.

Все немного по-другому для насмешек Мокито и шпионов. Макет Mockito позволяет нам заглушить вызов метода. Это означает, что мы можем заглушить метод для возврата определенного объекта. Например, мы можем смоделировать репозиторий Spring Data JPA в классе обслуживания, чтобы заглушить метод getProduct () из репозитория для возврата объекта Product. Чтобы запустить тест, нам не нужно, чтобы база данных была запущена и работала — чистый модульный тест.

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

Давайте рассмотрим макеты и шпионов в действии с приложением Spring Boot MVC.

Тестируемое приложение

Наше приложение содержит один объект JPA продукта. Операции CRUD выполняются на объекте с помощью ProductRepository с использованием CrudRepository, предоставленного Spring Data JPA. Если вы посмотрите на код, вы увидите, что все, что мы сделали, это расширили Spring Data JPA CrudRepository для создания нашего ProductRepository. В Spring Spring JPA предусмотрены реализации для управления объектами для самых распространенных операций, таких как сохранение объекта, его обновление, удаление или поиск по идентификатору.

Сервисный уровень разработан в соответствии с принципами SOLID . Мы использовали технику « Код в интерфейс », одновременно используя преимущества внедрения зависимостей. У нас есть интерфейс ProductService и реализация ProductServiceImpl. Именно этот класс ProductServiceImpl мы будем тестировать.

Вот код ProductServiceImpl.

ProductServiceImpl.java :

package guru.springframework.services;

import guru.springframework.domain.Product;
import guru.springframework.repositories.ProductRepository;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class ProductServiceImpl implements ProductService {
    private final Logger logger = LoggerFactory.getLogger(this.getClass());
    private ProductRepository productRepository;

    @Autowired
    public void setProductRepository(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Override
    public Iterable<Product> listAllProducts() {
        logger.debug("listAllProducts called");
        return productRepository.findAll();
    }

    @Override
    public Product getProductById(Integer id) {
        logger.debug("getProductById called");
        return productRepository.findOne(id);
    }

    @Override
    public Product saveProduct(Product product) {
        logger.debug("saveProduct called");
        return productRepository.save(product);
    }

    @Override
    public void deleteProduct(Integer id) {
        logger.debug("deleteProduct called");
        productRepository.delete(id);
    }
}

...
private ProductServiceImpl productServiceImpl;
@Mock
private ProductRepository productRepository;
@Mock
private Product product;

@Before
public void setupMock() {
    MockitoAnnotations.initMocks(this);
    productServiceImpl = new ProductServiceImpl();
    productServiceImpl.setProductRepository(productRepository);
}
...

@Test
public void shouldReturnProduct_whenGetProductByIdIsCalled() throws Exception {
    // Arrange  
    when(productRepository.findOne(5)).thenReturn(product);
    // Act   
    Product retrievedProduct = productServiceImpl.getProductById(5);
    // Assert     
    assertThat(retrievedProduct, is(equalTo(product)));
}

package guru.springframework.services;

import guru.springframework.domain.Product;
import guru.springframework.repositories.ProductRepository;
import org.junit.Before;
import org.junit.Test;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

public class ProductServiceImplMockTest {
    private ProductServiceImpl productServiceImpl;
    @Mock
    private ProductRepository productRepository;
    @Mock
    private Product product;

    @Before
    public void setupMock() {
        MockitoAnnotations.initMocks(this);
        productServiceImpl = new ProductServiceImpl();
        productServiceImpl.setProductRepository(productRepository);
    }

    @Test
    public void shouldReturnProduct_whenGetProductByIdIsCalled() throws Exception {
        // Arrange     
        when(productRepository.findOne(5)).thenReturn(product);
        // Act    
        Product retrievedProduct = productServiceImpl.getProductById(5);
        // Assert    
        assertThat(retrievedProduct, is(equalTo(product)));
    }

    @Test
    public void shouldReturnProduct_whenSaveProductIsCalled() throws Exception {
        // Arrange       
        when(productRepository.save(product)).thenReturn(product);
        // Act         
        Product savedProduct = productServiceImpl.saveProduct(product);
        // Assert         
        assertThat(savedProduct, is(equalTo(product)));
    }

    @Test
    public void shouldCallDeleteMethodOfProductRepository_whenDeleteProductIsCalled() throws Exception {
        // Arrange         
        doNothing().when(productRepository).delete(5);
        ProductRepository my = Mockito.mock(ProductRepository.class);
        // Act         
        productServiceImpl.deleteProduct(5);
        // Assert         
        verify(productRepository, times(1)).delete(5);
    }
}

when(mock.someMethod()).thenCallRealMethod();

package guru.springframework.services;

import guru.springframework.domain.Product;
import guru.springframework.repositories.ProductRepository;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class ProductServiceImplSpyTest {
    @Spy
    private ProductServiceImpl prodServiceSpy;
    @Mock
    private ProductRepository productRepository;
    @Mock
    private Product product;

    @Test(expected = NullPointerException.class)
    public void shouldThrowNullPointerException_whenGetProductByIdIsCalledWithoutContext() throws Exception {
        //Act
        Product retrievedProduct = prodServiceSpy.getProductById(5);
        //Assert
        assertThat(retrievedProduct, is(equalTo(product)));
    }

    public void shouldThrowNullPointerException_whenSaveProductIsCalledWithoutContext() throws Exception {
        //Arrange
        Mockito.doReturn(product).when(productRepository).save(product);
        //Act
        Product savedProduct = prodServiceSpy.saveProduct(product);
        //Assert
        assertThat(savedProduct, is(equalTo(product)));
    }

    @Test
    public void shouldVerifyThatGetProductByIdIsCalled() throws Exception {
        //Arrange
        Mockito.doReturn(product).when(prodServiceSpy).getProductById(5);
        //Act
        Product retrievedProduct = prodServiceSpy.getProductById(5);
        //Assert
        Mockito.verify(prodServiceSpy).getProductById(5);
    }

    @Test
    public void shouldVerifyThatSaveProductIsNotCalled() throws Exception {
        //Arrange
        Mockito.doReturn(product).when(prodServiceSpy).getProductById(5);
        //Act
        Product retrievedProduct = prodServiceSpy.getProductById(5);
        //Assert
        Mockito.verify(prodServiceSpy, never()).saveProduct(product);
    }
}