Как точно работает тест Spring JUnit, который использует заглушки?

Question

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

Например, у меня есть следующий слайд:

Так что я думаю, что это означает, что в производственной среде У меня есть класс AuthenticatorImpl, которая использует JpaAccountRepo службы \ хранилищу это зависимость, и это сама связана с некоторыми зависимостями и средой prodution (Spring, конфигурации и БД).

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

Таким образом, используя stub. Мне нужно создать заглушку предыдущей первой зависимости единицы, которую я хочу проверить. В этом случае JpaAccountRepo так что я могу создать общий AccountRepoStub, что это подделка реализация, которая не использует базу данных и не использовать конкретный TECNOLOGY для доступа к данным (я не испытывая JpaAccountRepo поэтому я может использовать поддельную реализацию, потому что это единичный тест, а не интеграционный тест).

Является ли это моим рассуждением прямо до сих пор?

Так, например, если это мой AuthenticatorImpl класс

public class AuthenticatorImpl implements Authenticator { 
    private AccountRepository accountRepository; 

    public AuthenticatorImpl(AccountRepository accountRepository) { 
     this.accountRepository = accountRepository; 
    } 

    public boolean authenticate(String username, String password) { 
     Account account = accountRepository.getAccount(username); 
     return account.getPassword().equals(password); 
    } 
} 

Как вы можете видеть конструктор AuthenticatorImpl() конструктор принять AccountRepository объект как paramether (который представляет собой интерфейс, а не реализация).

Так что я могу создать мой окурок класс с именем StubAccountRepository, которые реализуют AccountRepository интерфейса

class StubAccountRepository implements AccountRepository { 
    public Account getAccount(String user) { 
     return “lisa”.equals(user) ? new Account(“lisa”, “secret”) : null; 
    } 
} 

Так finnally я могу создать модульного тестирование реализации AuthenticatorImplTests класса

import org.junit.Before; import org.junit.Test; ... 

public class AuthenticatorImplTests { 
    private AuthenticatorImpl authenticator; 

    @Before 
    public void setUp() { 
     authenticator = new AuthenticatorImpl(new StubAccountRepository()); 
    } 

    @Test 
    public void successfulAuthentication() { 
     assertTrue(authenticator.authenticate(“lisa”, “secret”)); 
    } 

    @Test 
    public void invalidPassword() { 
     assertFalse(authenticator.authenticate(“lisa”, “invalid”)); 
    } 
} 

Так что в моем нАлАдкА метод я строю AuthenticatorImpl объект, проходящий к нему мой окурок StubAccountRepository так что я удалил связь с зависимостью и я тестирую только AuthenticatorImpl блок.

Правильно ли я что-то упускаю?

Tnx

Answer 1

У вас есть это.

В большинстве случаев вы не создаете класс Stub явно, но используете фальшивую фреймворк вроде Mockito, который создает его динамически для вас. Например:

AccountRepository stub = mock(AccountRepository.class); 
authenticator = new AuthenticatorImpl(stub); 

when(stub.getAccount("lisa")).thenReturn(new Account(“lisa”, “secret”));