Spring Данные: тестирование модуля уровня сервиса

Ответ 1

Одна из причин, по которой мне нравится тестировать мои репозитории данных Spring, - это проверить, что я правильно определил свои сопоставления JPA. Я не использую фальшивую структуру для этих тестов, я использую структуру Spring Test, которая фактически загружает контейнер, позволяя мне авторизовать фактический репозиторий в тесте Junit, чтобы я мог выполнять тесты против него.

Я согласен с вашими мыслями, что издевательство над репозиторием довольно бесполезно. Поскольку вы используете Spring, я бы предложил использовать платформу Spring Test для выполнения реальных тестов с вашими репозиториями, которые могут быть выполнены против встроенной базы данных, такой как H2, на основе более unit test или вашей реальной реализации базы данных, такой как Oracle или MySql, чтобы провести больше интеграционного теста. (Выполните их против копии базы данных разработки). Эти тесты выявят ошибки в ваших сопоставлениях JPA и других элементах, таких как неправильная настройка каскадов в базе данных.

Вот пример одного из моих тестов на GitHub. Обратите внимание на то, как инфраструктура фактически обновляет репозиторий в тесте. В репозитории также приведен пример настройки тестовой среды Spring, которую я также продемонстрировал в этом сообщении .

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

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

Ответ 2

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

• Я использую Mockito и JUnit.
• AccountRepository - это простой репозиторий данных spring, расширяющий JPARepository.
• Учетная запись - это простой объект JPA.

Чтобы протестировать ваши сервисы и издеваться над репозиториями spring Data, вам нужно что-то вроде ниже.

package foo.bar.service.impl;

import foo.bar.data.entity.Account;
import foo.bar.data.repository.AccountRepository;
import foo.bar.service.AccountService;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class AccountServiceImplTest {

    @Mock
    private static AccountRepository accountRepository;

    @InjectMocks
    private static AccountService accountService = new AccountServiceImpl();

    private Account account;

    @Test
    public void testFindAccount() {

        Integer accountId = new Integer(1);

        account = new Account();
        account.setId(accountId);
        account.setName("Account name");
        account.setCode("Accont code");
        account.setDescription("Account description");

        Mockito.when(accountRepository.findOne(accountId)).thenReturn(account);

        Account retrivedAccount = accountService.findAccount(accountId);

        Assert.assertEquals(account, retrivedAccount);

    }

}

Ответ 3

Ты точно прав. Ясно, что unit test. И он никогда не потерпит неудачу (так что это бесполезно). Я думаю, что вам нужно пройти тест интеграции, чтобы протестировать репозиторий JPA реального с помощью реальной базы данных (H2 в памяти, например) (как я всегда это делаю).

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

Через некоторое время вы будете удивлены, сколько проблем с DB\JPA (ограничения, оптимистичные блокировки, ленивая загрузка, дублированный идентификатор, некоторые проблемы с гибернацией и т.д.).

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

Итак, не создавайте тесты, чтобы их было много. Найдите, как они могут вам помочь.

Использование mocks для репозиториев - не очень хорошая идея. Проверьте, как ваши службы работают вместе с Hibernate\JPA\Database. Большая часть проблем находится beetwen layers.

Ответ 4

Вы можете использовать эту библиотеку: https://github.com/agileapes/spring-data-mock

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