Unit testing tests one unit of functionality and it keeps dependencies minimal and isolated from the environment, including Spring. We can use simplified alternatives for dependencies such as stubs and/or mocks.

In unit testing, there must not be any external dependencies, because external dependencies aren't available since we are testing a unit. So, remove links with dependencies. The test shouldn't fail because of external dependencies. You can remove external dependencies of your implementation for testing purposes by using stubs and mocks. Stubs create a simple test implementation and a mock dependency class generated at startup-time using a mocking framework.

Let's see the following diagram related to the unit testing example:

Here, you can see both modes of your application, the production mode and unit test mode. In the production mode, the Spring Framework injects dependencies by using the Spring configuration, but in the unit testing mode, Spring doesn't have any role, and dependencies have been resolved by creating stub implementations. The stub implementations are fake objection creation with dummy data.

In this example, I want to create a unit test for the AccountServiceImpl class and test two methods, findAccountByAccountId() and findAllByCustomerId(). The findAccountByAccountId() method will return the account object associated account ID and findAllByCustomerId() will return the list of accounts for a customer.

Let's create the AccountServiceImpl class and test this class with unit testing:

public class AccountServiceImpl implements AccountService { 
   @Autowired 
   AccountRepository accountRepository; 
 
   public AccountServiceImpl(AccountRepository accountRepository) { 
         this.accountRepository = accountRepository; 
   } 
   @Override 
   public Account findAccountByAccountId(Integer accountId) { 
         return accountRepository.findAccountByAccountId(accountId); 
   } 
   @Override 
   public List<Account> findAllByCustomerId(Integer customerId) { 
         return accountRepository.findAllByCustomerId(customerId); 
   } 
   ... 
} 

The preceding service class had a dependency with the AccountRepoistory implementation. Let's implement a stub implementation of AccountRepository for unit testing the AccountServiceImpl class:

public class StubAccountRepository implements AccountRepository { 
   ... 
   @Override 
   public Account findAccountByAccountId(Integer accountId) { 
         return new Account(100, 121.31, 1000, "SAVING", "HDFC121", 
   "HDFC"); 
   } 
    
   @Override 
   public List<Account> findAllByCustomerId(Integer customerId) { 
         List<Account> accounts = new ArrayList<>(); 
         accounts.add(new Account(100, 121.31, 1000, "SAVING", 
    "HDFC121", "HDFC")); 
         accounts.add(new Account(200, 221.31, 1000, "CURRENT", 
     "ICIC121", "ICICI")); 
         return accounts; 
   } 
   ... 
}

The StubAccountRepository class is a stub implementation of AccountRepository, by implementing methods with dummy data without calling the actual database. Let's see the following diagram that explains the two implementations of AccountRepository:

According to the preceding diagram, our application has two implementations of AccountRepository. JPAAccountRepository is used at the production mode, using database integration, but another class, StubAccountRepository, is used for unit testing without integrating database dependency. Let's see the following class to create a unit test using this stub repository:

AccountServiceImplTest is a unit test using a stub repository. Refer to the following code:

package com.dineshonjava.accountservice; 
 
import static org.junit.Assert.assertFalse; 
import static org.junit.Assert.assertTrue; 
 
import org.junit.Before; 
import org.junit.Test; 
 
import com.dineshonjava.accountservice.repository.StubAccountRepository; 
import com.dineshonjava.accountservice.service.AccountService; 
import com.dineshonjava.accountservice.service.AccountServiceImpl; 
 
public class AccountServiceImplTest { 
    
   AccountService accountService; 
    
   @Before  
   public void setUp() { 
       accountService = new AccountServiceImpl( new 
       StubAccountRepository() ); 
   } 
    
   @Test  
   public void findAccountByAccountId() { 
   assertTrue(accountService.findAccountByAccountId(100).getBalance().intValue() == 121); 
   } 
    
   @Test  
   public void findAllByCustomerId() { 
         assertFalse(accountService.findAllByCustomerId(1000).size() == 
        3); 
   } 
} 

The preceding class has three methods. The setup() method initializes AccountRepository; it is annotated with the @Before annotation. That means setup() will be called before the test methods execute. The other two methods, findAccountByAccountId() and findAllByCustomerId()), in the testing class are test methods and are also annotated with the @Test annotation, which indicates that these are test methods. We have testing logic inside these testing methods and we are using assertions to write the test logic.