Posted on by Vijay Redkar

BankNext Case Study: JUnit Mockito Automation

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


CategoriesUncategorized