BankNext Case Study: JUnit Mockito Automation
In this article, learn how to automatically produce JUnits for your SpringBoot application. Increase the code coverage across the application.
Join the DZone community and get the full member experience.
Join For FreeBankNext’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
- Time-intensive activity to write proper useful JUnits manually.
- Lacks standardization because each one takes different approaches.
- Deficient/incorrect JUnits are created due to lack of time.
- Manual sync-up of existing JUnits due to changing code is impractical.
- Writing JUnits manually for legacy code is a nightmare.
- The least priority is allotted to JUnits due to deadlines; hence gets skipped.
- Code quality suffers immensely, and technical debt piles up.
Solution: JUnit-Mockito Automation
- GitHub
- Automation takes in the Class name and creates a legal working JUnits.
- These generated JUnits contain the necessary Mockito mocks.
- Handles JUnits for RestControllers, Services, Handlers, Kafka classes, etc.
- Thus, it accomplishes > 70% code coverage in almost all scenarios.
Automation Capabilities
- Works for both SpringBoot 2.x and 3.x Maven-based applications.
- Almost zero setup effort.
- Takes the local path of your application & very basic user inputs.
- Utilizes Reflection utils to deduce application structure details.
- Seamlessly identify the required Mockbeans.
- Automatically generates “When-Then” Mockito mocks.
- Generates Jacoco code coverage reports.
Structure of a Legal JUnit
- Mandatory portions: 3
- Invoke the target test method
- Mock any interactions that are external to this class
- Check the actual output matches the expected assert/verify
- Identify and declare all external classes as MockBeans
- Stub the expected responses from these MockBean interactions
- Below are the ground rules for a basic legal working JUnit
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
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
Conclusion
- BankNext saves enormous time and effort with/ automatic JUnit creation.
- This translates directly into saving project expenses.
- Code coverage increases immensely.
- The team is able to focus completely on real development activities.
- JUnits added/maintained consistently with/ almost zero manual effort.
- Technical debt is reduced vastly.
- Greatly enhances confidence in applications deployed to production.
Published at DZone with permission of Vijay Redkar. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments