BankNext Case Study: JUnit Mockito Automation

Tutorials
JUnit

BankNext’s massive production environment has more than 300 live microservices. Multiple squads working concurrently on these SVCs heightens the risk of breaking functionality. Adding JUnits and code coverage manually to existing and new code is arduous and painfully slow.

Challenges With Manual JUnits

  1. Time-intensive activity to write proper useful JUnits manually.
  2. Lacks standardization because each one takes different approaches.
  3. Deficient/incorrect JUnits are created due to lack of time.
  4. Manual sync-up of existing JUnits due to changing code is impractical.
  5. Writing JUnits manually for legacy code is a nightmare.
  6. The least priority is allotted to JUnits due to deadlines; hence gets skipped.
  7. Code quality suffers immensely, and technical debt piles up.

Solution: JUnit-Mockito Automation

  1. GitHub 
  2. Automation takes in the Class name and creates a legal working JUnits.
  3. These generated JUnits contain the necessary Mockito mocks.
  4. Handles JUnits for RestControllers, Services, Handlers, Kafka classes, etc.
  5. Thus, it accomplishes > 70% code coverage in almost all scenarios.

Automation Capabilities

  1. Works for both SpringBoot 2.x and 3.x Maven-based applications.
  2. Almost zero setup effort.
  3. Takes the local path of your application & very basic user inputs.
  4. Utilizes Reflection utils to deduce application structure details.
  5. Seamlessly identify the required Mockbeans.
  6. Automatically generates “When-Then” Mockito mocks.
  7. Generates Jacoco code coverage reports.

Structure of a Legal JUnit

  1. Mandatory portions: 3
    1. Invoke the target test method
    2. Mock any interactions that are external to this class
    3. Check the actual output matches the expected assert/verify
  2. Identify and declare all external classes as MockBeans
  3. Stub the expected responses from these MockBean interactions
  4. Below are the ground rules for a basic legal working JUnit
Shell

  

Junit-Mockito  Ground Rules

1- target mtd to be tested createCustomer is a void returnType   
2- external mtd invoked .delete     is a void returnType
3- when-then   :  doNothing whenInvoke .delete
4- assertion    :  verify .delete called 1 times  

1- target mtd to be tested createCustomer is a void returnType   
2- external mtd invoked .save          is a Customer returnType
3- when-then   :  when  save then return new Customer
4- assertion    :  verify .save called 1 times

1- target mtd to be tested createCustomer is a Customer returnType   
2- external mtd invoked .save          is a Customer returnType
3- when-then   :  when  save then return new Customer
4- assertion    :  assert result instanceof Customer / Customer is not null

1- target mtd to be tested createCustomer is a Customer returnType   
2- external mtd invoked .findAll          is a List returnType
3- when-then   :  when findAll then return new ArrayList
4- assertion    :  assert result instanceof List / List.size >0

Automation Demo

View the demo here.

Shell

  

cd C:\Vijay\Java              [your local machine path]
git clone https://github.com/vijayredkar/junit-mockito-automation.git

# My final directory structure
# C:\Vijay\Java\AutomationJunitMockito\appsetup
# C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\junit-automation 

cd C:\Vijay\Java\AutomationJunitMockito\appsetup
setup.bat

------- Demo Steps ------
https://vijayredkar.medium.com/banknext-case-study-junit-mockito-automation-ac9f6b72cfcc
https://github.com/vijayredkar/junit-mockito-automation

C:\Vijay\Java\AutomationJunitMockito\appsetup

demo scenario -1
com.banknext.customer.mgt.service.CustomerServiceImplType1   
com.banknext.customer.mgt.controller.CustomerMgtControllerType1 

demo scenario -2
com.banknext.customer.mgt.service.CustomerServiceImplType2   
com.banknext.customer.mgt.controller.CustomerMgtControllerType2                 

demo scenario -3
com.banknext.customer.mgt.event.publisher.CustomerTxnPublisherType1             
com.banknext.customer.mgt.event.consumer.CustomerTxnConsumerType1               

demo scenario -4
https://github.com/bezkoder/spring-boot-h2-database-crud/tree/master
cd C:\Vijay\Java\projects\junit-mockito-mgt\test-projects
#git clone https://github.com/bezkoder/spring-boot-h2-database-crud.git
cd C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\spring-boot-h2-database-crud
mvn clean install

cd C:\Vijay\Java\AutomationJunitMockito\appsetup
run setup.bat

cd C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\spring-boot-h2-database-crud
mvn clean install
import in Eclipse
add POM dependencies
check current Jacoco code coverage
 

continue automation run 
check/adjust generated Junits
check current Jacoco code coverage
cd C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\spring-boot-h2-database-crud

check new Jacoco code coverage

run all tests 
cd C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\spring-boot-h2-database-crud
mvn clean install
check again all Jacoco code coverage

C:\Vijay\Java\projects\junit-mockito-mgt\test-projects\spring-boot-h2-database-crud\src\main\java\com\bezkoder\spring\jpa\h2
com.bezkoder.spring.jpa.h2.controller.TutorialController
com.bezkoder.spring.jpa.h2.model.Tutorial
TutorialController

Before and After Automation Run

junit-mockito-automation

customerservicelmpltype2

Conclusion

  1. BankNext saves enormous time and effort with/ automatic JUnit creation.
  2. This translates directly into saving project expenses.
  3. Code coverage increases immensely.
  4. The team is able to focus completely on real development activities.
  5. JUnits added/maintained consistently with/ almost zero manual effort.
  6. Technical debt is reduced vastly.
  7. Greatly enhances confidence in applications deployed to production.

Source:
https://dzone.com/articles/banknext-case-study-junit-mockito-automation-1