Category Archives: junit

Junit : Best Practices


In the previous topics we learn about the unit testing by Junit and implementation of Test Cases by using Junit 5. In this topic we will learn about the some Junit Best Practices and Why it’s required.

Why JUnit Best Practice Needed?

When writing Junit test case, we need to ensure the following points:

  • Test cases should be easily readable
  • Test cases should be extremely consistent and reliable
  • It should indicate the real issues in the production code
  • Tests should fail only when there is a bug in the system
  • It will be good if more test cases executed frequently
  • All the test cases should execute very fast

You can achieve all these Junit features when apply the “Junit Best Practices” when writing the Junit Test cases.

What is the Junit Best Practices for Test Case writing?

These are some high-level points that’s need to keep in mind while writing the test cases for an application or project.

  • Test cases should be readable.
  • The name of the test class and test methods should be descriptive.
  • Develop the JUnit test cases in a way that it should execute faster.
  • Always first plan unit tests for functionalities that have fewer dependencies.
  • Plan for proper tests for all functionalities.
  • Don’t use test case constructor to setup test cases.
  • Avoid skipping test cases with the usage of @Disabled without any reason, a reason could also be passed for @Disabled for any developer to know why a particular test case was is skipped.
  • Each unit test method should have only one assertion.
  • Maintain proper order of parameters in assertions.
  • Practice the resilient assertions.
  • Make each test independent of all others.
  • Don’t go for unit-testing of any settings or configuration.
  • Confirm that unit test code is parted from production code.
  • Do not print anything out in unit tests.
  • Avoid the usage of static members inside the test class, if you have used then re-initialize on each test case.
  • Do not give your own exception that occurs only to fail a test.
  • Don’t write testcases for configuration settings.
  • Plan to run the test cases completely in-memory, avoid doing a test for availing file system and DB, and for HTTP requests, Use mocking Junit framework like Mockito etc. for external or third-party dependency.
  • Implement Code Coverage tools like Cobertura, JACOCO etc. with your project so that verify that written Junit Test cases covering complete code. As per industry standard code coverage ratio should configure as 80%.
  • Integrate test cases with build script(ant or maven or gradle) so that all Junit test case will execute before your application ready for deploy.
  • Capture the results using XML formatter so that make test case report readable with color text.

Note: While writing test case assume these test cases will not execute in sequence so never try to use one test case result on another test case.

Good Tips for Junit Test Cases Writing

Here are some good tips for Junit Test Cases Writing that will guide when writing the test cases for any method in class.

  • Write descriptive name of your test case
TestCreateUser_NullUserId_ShouldThrowException
TestCreateUser_DuplicateUserId_ShouldThrowException
TestCreateUser_ValidUserId_Should_Pass
  • When writing test cases for method arguments then check for each parameters of method for null and these methods should return Invalid parameter exception if any parameter is null.
  • After null unit test implementation write test for functional unit.
  • Each test case should have only one assertion and it should cover one functional condition of code. Like if-else, switch, loops, exception etc.
  • For some methods where need to meet SLA of time or dependent of third-party API result write test cases for @Timeout.
// Timeout after 3 nanoseconds
@Timeout(value = 3, unit = TimeUnit.NANOSECONDS) 
@Test
void annotationDelayInValidTest() throws InterruptedException {
		obj.delay(2); // Delay for 2 seconds
}

JUnit 4

@Test(expected=ArithmeticException.class)
public void testCalculatorDivide()
{
assert(5, obj.devide(5,0))
}

JUnit 5

@Test
void testCalculatorDivide() {
Exception exception = assertThrows(ArithmeticException.class, () -> cobj.division(5, 0));
assertEquals("divide by zero", exception.getMessage());
	}
  • If need to test particular test case for multiple parameter values then write test case as @ParameterizedTest
@ParameterizedTest
	@NullAndEmptySource
	@ValueSource(blankStrings = { " ", "   ", "\t", "\n" })
	void checkText(String sampleText) {
	    assertTrue(sampleText == null || sampleText.trim().isEmpty());
	}

  • Use @Before and @After or @BeforeAll or @AfterAll test method for Initialization and close the dependencies of test method.
  • Use Mocking Junit framework for testing external service or DB related methods.
  • Don’t write test cases for configuration and constant related classes.
  • Ensure tests that are time dependent so that test data will not consider as expired data.
  • Use local when using date and time while implementing test cases.
  • Keeps your test cases on test packages in same project so that maintain easily and skip also in case required.

Summary

No doubt writing Junit increase the code quality of the code and by following the best practices reduce the maintenance and execution time of test. If you keep above points in mind that will help you to write good quality of test cases and make your application reliable and reduce the regression testing time with less defects in your code.

Let me know your views for Junit implementation and Junit Best Practices for writing Unit test cases for your code.

JUnit 5 : Environment Setup


Let us discuss on JUnit 5 environment setup in Java Application.

Pre-Requisite

JUnit 5 does not required any major setup. It’s required following library and IDE:

  • JDK : Min 1.8 or above
  • IDE : Eclipse/STS or Netbean or IntelliJ
  • Latest version of Junit 5 is readily available with latest version of IDE

More :

Junit 5 Setup in Java Application

You can add JUnit 5 library in your Java Application by follow below steps:

  • Right clock on your project -> Properties->Build Path-> Configure Build Path
  • Select Junit Library by following below steps in screen shot.
Junit 5 Environment Setup
  • After clicking in Next button (Step 5). You will get below screen where you can select Junit 5.
JUnit 5 Environment Setup
  • After click on Finish button (Step 7) this JUnit 5 library will add on your application.
  • Now you can click on “Apply” or “Apply and Close” button to complete this process.

Now your application is setup to write test JUnit 5 test cases.

In further topic you will learn about how to write JUnit Test Cases.

Junit 5 : How to write JUnit Test Cases?


In previous topic you learn about the JUnit setup in Java Application. In this topic you will learn about the Junit test cases writing of methods for particular java class.

Lets discuss about the test cases writing in Java application.

  • Right click on your java project -> Select New -> Junit Test Case as below.
How to write Junit Test Cases in Java application
  • After selecting the Junit Test Cases you will get below screen. Here the Jupiter option (Step 1) is for implementing the Junit Test cases with Junit 5. You can write test class name (Step 2) as CalcularTest and also select Fixture (Step 3) if initialization required for your test cases.
How to write Junit Test Case with Junit 5
  • Instead of writing the test cases, If you want to generate the Test cases for particular class then select browse (step 4) option and you will get below screen where you can search for class.
How to generate Junit test cases for particular class
  • After selecting class, click on OK button. You will get next screen with names of method where you can select methods for which you want to generate the test cases.
How to generate Junit test cases
  • After selecting methods click on Finish button, you will see a class CalculatorTest.java class added in you application with some test cases code as below.

CalculatorTest.java

JUnit Test Cases Generated
  • Now your some test cases generated with some dummy code where you can write your own logic inside of these test method by using assertion or assumption and run these test cases.

How to run Test Junit Cases?

Once you will done with the test case writing. You can follow these steps to run test cases:

  • Right click on your Java Application->select run as -> Junit
  • After executing the test cases you will see the test case result as below with red and green colors. Where green represent success and red as failure of test cases.

Junit Failed Cases

Junit some test cases failed

JUnit Success Case

Junit all success

Here I have done some changes in auto generated test cases as below and after execution showing as success as above. You can try with same or update it.

JUnit for success case

In the further topic you will learn more about the Junit 5 Annotations, Fixtures, Assertions and Assumptions in detail with examples.

Junit 5 : Architecture


Junit 5 Architecture mainly divide in three modules:

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

JUnit 5 Architecture

In Junit 5 Architecture each module having specific purpose as below:

JUnit Platform

Junit Platform is core of JUnit 5 which provides a bunch of libraries that provide Console Launcher to launch a platform from the command line and invokes JUnit Runner for running Test Engine in JUnit 4 based environment.

JUnit Jupiter

Jupiter provides the APIs for developer to interact assertions and assumptions instead of Runner itself.

JUnit Vintage

By default, JUnit 5 does not provide backward compatibility, instead, it uses another module called as Vintage which provides APIs to write test cases supported by older version JUnit 3 or Junit 4.

Extensions (Third Party)

JUnit 5 supports third-party APIs also on its platform with the help of the Extensions module.

In further topics you will learn about the JUnit 5 Annotations and Implementation of test cases by considering different scenarios.

JUnit 5: Introduction


In the previous topic you learned about the JUnit introduction and compare between different Junit framework like Junit vs TestNG. Here we will discuss about some important points to remember about Junit 5.

  • JUnit 5 is the latest version of JUnit which require a minimum JDK 8 version.
  • Junit 5 supports popular IDEs such as Eclipse/STS and IntelliJ for test case executions.
  • Junit 5 supports all new Java Language features including Lambdas.
  • Junit 5 provides various assertions and assumptions.
  • Junit 5 provides a whole new architecture that is comprised of modules, making it suitable to be used in small memory-based systems.
  • Junit 5 vintage module supports backward compatibility with previous version Junit 3 and Junit 4.

In the further topic you will learn about the JUnit 5 Architecture, JUnit 5 Annotations and Implementation of test cases by considering different scenarios.

JUnit Introduction


  • JUnit is an open-source framework for Java programming language, used to write and run automated unit test cases. It is widely accepted as a standard for unit testing in Java.
  • JUnit is a simple testing framework created by Kent Beck and Erich Gamma during a long airplane trip.
  • It is released under IBM’s common public license version 1.0 and hosted on SourceForge.
  • Till JUnit 3.8 there were no stable versions.
  • It is the Java version of the xUnit architecture for unit and regression testing frameworks
  • According to a survey of 2013, 10,000 Java projects hosted on GitHub were using JUnit as a testing framework.
  • In this tutorial, we will perform unit testing with JUnit 5 which is the latest stable JUnit version.

In the further topics we will discuss more about the Junit basics and implementation of test cases by using JUnit 5 after considering different scenarios and backward compatibility with previous version JUnit 3 and JUnit 4.

Unit Testing


Unit testing is process of Software development which validate that each unit/line of code is performing as expected or not. On broader prospect Unit Testing is defect prevention and detection strategy to reduce software development risks, cost, and time to deliver a quality software.

Developers write Unit Test cases which covers the functionality of specific section of code, function level, class level and branches level so that ensure the implemented code is working as expected. Unit testing not completely verify the functionality of software but it’ ensure that building block of software work independently as expected from others.

Why Unit Testing Framework?

In Unit Testing, we verify each section of code for success and failure scenarios where need to implement the conditions in code Test code by considering the different cases.

Let’s take the below examples of Calculator.java class on addition() method where need to verify output of result by considering different test cases for success and failure.

Calculator.java

public class Calculator {
		public int addition(int a, int b) {
			return a + b;
		}
	}

Test Cases Implementation

In this case for testing this method we need to create one test class i.e CaculatorTest.java and implement the condition for all scenarios of every method test as follows:

Success Case: Pass arguments as a=2, b=3 return result=5, Expected Result =5

Failed Case: Pass arguments as a=2, b=3 return result=Other, Expected Result=5

class CalculatorTest {
private static final Logger logger = Logger.getLogger(CalculatorTest.class.toString());
private Calculator calc = new Calculator();
		void additionTest() {
		int sum = calc.addition(2, 3);
		if (sum == 5) {
		logger.info("Addition method test has passed.");
		} else {
		logger.info("Addition method test has failed.");
			}
		}	
		public static void main(String[] args) {
			CalculatorTest cTest = new CalculatorTest();
		cTest.additionTest();
	}	
	}

Here if you noticed for testing a single small addition() method required to write these many lines of code for creating object of Calculator class, calling method and check for pass and failed scenarios. Apart from it you need monitor the console logs also for verify the expected result. Think of when there are multiple methods in class and software having lots of classes on that case writing Junit code is cumbersome process for developers.

From the above example, Now analyze tasks that need to be done manually with and without framework :

TaskWithout FrameworkWith Framework
PreparationManually Manually
Provide Test Inputs Manually Manually
Run the tests Manually Framework
Provide expected outputs Manually Manually
Verify results Manually Framework
Notify developer if test failed Manually Framework

Now it should be clear that how important to use framework because it saves significant amount of time of developers.

There are lots of framework for Unit Testing but when we talk about the Java unit testing mainly these two are most popular.

  1. Junit
  2. TestNG

TestNG is a testing framework for Java and is inspired by JUnit and NUnit which covers a wide range of testing like unit testing, functional testing, integration testing, and system testing.

In the further topics we will discuss more about the Junit basics and implementation of test cases by using Junit 5 after considering different scenarios.

Software Testing


What is Software Testing?

When developer create a new software and deploy in market for use of public. The success of software depends on popularity of software, but it becomes terrible when users complains bugs, issues in the software. In this case developer need to debug the issues and fixed again for release the software that’s time-consuming process.

To overcome this practice “Software testing” comes in picture. This activity makes sure that every functionality or component of software is working as expected and outcome of software is as expected. The main purpose of software testing is delivered as defect free software.

Why Software Testing?

“Prevention is better better than care”

This phrase is very well suite for software development, If developers do the software testing on the time of development then all the issues will identify and fixed on the time of development which will make the bug free software. Software testing saves a lot of time for developers and reduces the frustration level caused by detecting bugs after deployment.

Software Testing Types

Software testing mainly categories in two types:

Software Testing Types
  1. Manual Testing: In this testing strategy is done manually by a tester to discover the bugs in software and check the results. This is also required because 100% automation testing is not possible.
  2. Automated Testing: In this testing, scripts and codes are written by testers to automate the test cases execution. This testing strategy saves lots of time as well manpower and generate report by automation tool.

Software Testing Hierarchy

In software testing, whether you choose automation or manual testing it can’t complete on one go. It comprises through 4 testing levels as below:

Software Testing Hierarchy

Unit Testing

Unit testing covers all independent parts or components of code i.e. known as Units. Unit testing is the first level of testing which perform on time of the development phase by developers while developing the software.

Integration Testing

Once the unit testing is working fine of all units of code then testing will be preform after integrating them i.e. called the integration testing. In this testing we check the communication between each unit are working as expected or not.

System Testing

Once the integration testing completed for all modules, then testing start for complete software i.e. called as System testing.

Acceptance Testing

After completing the System testing the software is evaluate as per business requirements i.e. called as Acceptance Testing. Once acceptance testing is completed successfully the software deployed to market for general user’s access.

The above testing hierarchy is very high level, there are other sub phases also for software testing, you will get to know by following this link https://en.wikipedia.org/wiki/Software_testing

In the further topics we will discuss more on Unit Testing by using Junit 5 and implementation on time of development.

Junit: Jacoco Code Coverage Plugin Integration with Eclipse/STS


In previous post you learn about the Junit Code Coverage Report generation by using Maven POM.xml that’s help to generate report for auditing purpose and check the status of junit test case implementation but everytime for these report you have to visit directory target/site/jacoco/index.html or target/jacoco-report/index.html

To reduce this effort, we can add this Jacoco plugin our eclipse/STS IDE and directly check the status over IDE.

Integration of JACOCO Code Coverage Plugin in Eclipse/STS

You can follow these steps to integrate this JACOCO code coverage plug in you eclipse or STS IDE.

  • Go to IDE top header Help->Eclipse Market Place it will open the pop up for Eclipse Market Place.
  • Type text as “Code Coverage” in search text box and click “Go” button. You will get below screen
JACOCO Code Coverage Plugin for Eclipse/STS
  • You will get list of plugins select the plugin “EclEmma Code Coverage” click on Install button for this plugin.
  • You will get next screen where need to accept terms and conditions and click continue.
  • After installing this code coverage plugin, It will ask to restart your IDE.
  • After restart your IDE, go to the top Windows->Show View->Others then search for “Coverage” as below then select option click on Open button.
  • You will see one additional tab “Coverage” on your console view section as below.
Coverage tab on view
  • Also get “Coverage As” option as below when right click on your application. Now you can run you Junit.
JACOCO coverage as option
  • Once you run your application Junit by using “Coverage As” option you will see the results on “Coverage” tab as below.
JUnit Code coverage report by Eclipse/STS plugin

To learn more detail about this report and metrics header you can follow this link Junit: Code coverage by using JaCoCo.

Conclusion

In this topic you learn about the steps to add code coverage plugin in you eclipse/STS IDE.

If this port help you to add Code Coverage plugin in you eclipse/STS IDE the like this post and share your comments. In case you are facing issue related to code coverage implementation share with us will try to resolve it.

Junit: Code coverage by using JaCoCo


Why Code Coverage Require while writing JUnit?

Code coverage is a matric indicator that shows the line of code are executed while running the automated JUnit test cases. This helps developer to identify that any unit test is not missing for developed code or newly added functionality of code so that improve the code quality and reduce number of bugs on time of integration testing.

While audit of your application source code auditor also asked for Code Coverage report so that observe your written Junit test cases covering complete application or not.

For Java development there are couple of tools for Code Coverage like Cobertura and Jacoco etc. Here you will learn about the integration of JACOCO with maven project.

JCOCO Code Coverage Plugin Integration with Eclipse/STS

Note : Cobertura support till Java version 8 only while JACOCO support all the Java 5 and above.

Code Coverage Tools generate report in percentage ratio as below in screen shot. Each header section described in detail in this table.

Junit Code Coverage

You can further extend this package section to get more code coverage detail on class and method level. You will get to know more detail in further sections.

Here these color represent as :

  • Green: Code is tested or covered
  • Red: Code is not tested or covered
  • Yellow: Code is partially tested or covered
HeaderDescription
INSTRUCTION
BRANCHAll the if-else or switch statements are consider as branch and represent as diamond in a method that can be executed or missed.
No coverage (Red diamond): No branches in the line has been executed.
Partial coverage (Yellow diamond): Only a part of the branches in the line have been executed.
CYCLOMATIC COMPLEXITYhttps://en.wikipedia.org/wiki/Cyclomatic_complexity
LINEConsider as executed when at least one instruction that is assigned to this line has been executed.
No coverage (Red): No instruction in the line has been executed.
Partial coverage (Yellow): Only a part of the instruction in the line have been executed.
Full coverage (Green): All instructions in the line have been executed
METHODConsider as executed when one of the instruction has been executed.
CLASSConsider as executed when one of the method has been executed.
JUnit Code Coverage Criteria

Implementation of Code Coverage

In this further section you will learn about the implementation of Code Coverage for Junit. Here we are using dependency as below:

  • JUnit 5
  • Maven 4
  • Maven Surefire plugin 3.0.0-M5
  • Jacoco 0.8.2 (Code Coverage library)

POM.XML

You can make following changes in your maven java application pom.xml.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.FacingIssuesOnIT</groupId>
  <artifactId>maven-junit-code-coverage-Jacoco</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <name>Maven-junit-CodeCoverage-Jacoco</name>
  <description>Maven JUnit Code Coverage</description>
  <properties> 
     <maven.compiler.source>1.8</maven.compiler.source>
     <maven.compiler.target>1.8</maven.compiler.target>    
	<java.version>1.8</java.version>
	<!-- add property to enable or disable code coverage by default id false for Jacoco -->
	<jacoco.skip>false</jacoco.skip>
</properties>
<dependencies>
<!-- Junit 5 -->
	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter-engine</artifactId>
		<version>5.5.2</version>
	</dependency>
</dependencies>
	<build>
		<plugins>
		<!-- Maven plugin for surefire with Dependency junit 5 -->
			<plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.0.0-M5</version>
            <dependencies>
                <dependency>
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter-engine</artifactId>
                    <version>5.5.2</version>
                </dependency>
            </dependencies>
        </plugin>
        <!-- Jacoco plug in for code coverage -->
			<plugin>
				<groupId>org.jacoco</groupId>
				<artifactId>jacoco-maven-plugin</artifactId>
				<version>0.8.2</version>
				<configuration>
					<!-- exclude classes for code coverage -->
					<excludes>
						<exclude>**/*fiot/*Application.class</exclude>
						<exclude>fiot/controller/*</exclude>
					</excludes>
				</configuration>
				<executions>
					<execution>
						<goals>
							<goal>prepare-agent</goal>
						</goals>
					</execution>
					<!-- attached to Maven test phase -->
					<execution>
						<id>jacoco-report</id>
						<phase>test</phase>
						<goals>
							<goal>report</goal>
						</goals>
						<!-- default target/site/jacoco/* you can define your directory for code coverage report -->
						<configuration>
							<outputDirectory>target/jacoco-report</outputDirectory>
							<skip>${jacoco.skip}</skip>
						</configuration>
					</execution>
					<!-- Define rule for successful build based on code code coverage criteria -->
					<execution>
						<id>jacoco-check</id>
						<goals>
							<goal>check</goal>
						</goals>
						<configuration>
							<rules>
								<rule>
								<!-- When code coverage is 90% and no class missed then consider for successful build -->
									<element>PACKAGE</element>
									<limits>
										<limit>
											<counter>LINE</counter>
											<value>COVEREDRATIO</value>
											<minimum>0.9</minimum>
										</limit>
										<limit>
											<counter>CLASS</counter>
											<value>MISSEDCOUNT</value>
											<maximum>0</maximum>
										</limit>
									</limits>
								</rule>
							</rules>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</project>

Here is more detail about the Jacoco code coverage implementation.

Maven Junit Code Coverage Implementation Detail

Now lets create some classes by some code implantation and check this code coverage implementation by implementing Junit.

Here i have created one Maven Java project with below directory/file structure.

Maven Junit Code Coverage Example

Implement some code as below:

Calculator.java

package com.FacingIssuesOnIT;

public class Calculator {

	   public double divide(int a, int b)
	   {
		   if(b==0)
		   {
			   throw new ArithmeticException();
		   }
		   else
		   {
		   return a/b;
		   }
	   }

	    public int multiply(int a, int b) {
	        return a * b;
	    }
	    
	    public int add(int a, int b) {
	        return a + b;
	    }
}

Address.java

package com.FacingIssuesOnIT;

public class Address {
  public String printAddress()
  {
	  return "Facing Issues On IT \n Learn from Others Experience";
  }
}

CalculatorTest.java

You can write your own Junit test cases or use in git hub by following below link. Maven JUnit Code Coverage Example

Junit Test Cases

Code Coverage report

After writing test cases you can execute same by mvn test and verify the report in folder {application path}/target/jacoco-report/index.html

It will generate report as mentioned in below screen. Here Green percentage showing code coverage for JUnit while red showing for missing Junit for code.

Maven Junit Code Coverage Report

To get in-depth detail on code coverage on class and method level you can extend by clicking package.

Maven Junit code coverage report on class level

On further extend by click on class you will het detail on method level.

Maven Junit Code Coverage report on method level

On further extend by click on particular method you will get detail about the line and branch level code coverage.

Maven JUnit Code Coverage on Line and branch level

After collecting all such information you can write junit test cases for all these missing lines/method/branch (red) of statements.

Code Coverage Rules for application build

In the above example, I have define rule for code coverage as 90% instruction execution and missing class as 0. Even If our implemented Junit executed successfully but code coverage criteria is not match with define rules then our maven install will fail and throw exception as below .

[ERROR] Failed to execute goal org.jacoco:jacoco-maven-plugin:0.8.2:check (jacoco-check) on project maven-junit-code-coverage-Jacoco: Coverage checks have not been met. See log for details. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

Once all the missing Junit will implement and criteria will match successful then build sucessfully.

Conclusion

In this blog you learn about the implementation of code coverage for Unit and defining rule to make build. Some times while audit of you application code quality auditor also asked about the JUnit code coverage report so that auditor can verify the written Junit covering the complete source code of your application.

References

https://www.eclemma.org/jacoco/trunk/doc/maven.html

Source Code

Download Maven Junit Code Coverage Source Code

If this example this Junit Code Coverage detail help you like post make comments. In case you are facing any issue while implementing share detail will try to help you.

[Solved] org.mockito.exceptions.misusing.UnnecessaryStubbingException


UnnecessaryStubbingException is runtime and sub class of MockitoException. Mockito JUnit Runner triggers UnnecessaryStubbingException only when none of the test methods use the stubbings. This means that it is ok to put default stubbing in a ‘setup’ method or in test class constructor. That default stubbing needs to be used at least once by one of the test methods.

Constructors

  • UnnecessaryStubbingException(String message) : Will throw exception with message.

Example

//code test:
 String result = translator.translate("Saurabh");

//Mock:
// <- stubbing used during code execution
 when(translator.translate("Saurabh")).thenReturn("Gupta");
// <- stubbing never used
when(translator.translate("Gaurav")).thenReturn("Gupta");

Solutions

It is highly recommended to remove unused stubbings to keep the codebase clean. You can opt-out from detecting unused stubbing using MockitoJUnitRunner.Silent() or MockitoRule.silent() (when you are using Mockito JUnit rules.

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/UnnecessaryStubbingException.html

Know More

To know more about Junit, Mockito and exception solutions follow below links:

[Solved] org.mockito.exceptions.misusing.PotentialStubbingProblem


PotentialStubbingProblem is a RuntimeException and subclass of MockitoException. Mockito framework throws this exception when “stubbing arguments mismatch“.

Strict stubbing is a new opt-in feature for JUnit Rule and JUnit Runner to detect potential stubbing problems org.mockito.exceptions.misusing.PotentialStubbingProblem exception is thrown when mocked method is stubbed with some argument in test but then invoked with different argument in code.

This exception can occurred by many reasons:

  1. Mistake or typo in the test code, the argument(s) used when declaring stubbing’s is unintentionally different.
  2. Mistake or typo in the code under test, the argument(s) used in the code under test is unintentionally different.
  3. Intentional use of stubbed method with different argument, either in the test (more stubbing) or in code under test.

Constructors

  • PotentialStubbingProblem(String message) : Will throw exception with message.

Example

 //test method:
 given(mock.getSomething(200)).willReturn(something);

 //code under test:
// stubbing argument mismatch
 Something something = mock.getSomething(100);

Solutions

public class TestExample {
     @Rule
     public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.STRICT_STUBS);

     @Test public void exampleTest() {
         //Change the strictness level only for this test method:
         mockito.strictness(Strictness.LENIENT);

         //remaining test code
         given(mock.getSomething(200)).willReturn(something);
         //Will work
         Something something = mock.getSomething(100);

     }
 }

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/PotentialStubbingProblem.html

Know More

To know more about Junit, Mockito and exception solutions follow below links:

[Solved] org.mockito.exceptions.misusing.RedundantListenerException


RedundantListenerException is RuntimeException and sub class of MockitoException. This occurred by Mockito framework when  instance of MockitoListener is being added to Mockito Framework and there is already a listener with this implementation type registered.

Note : It is ok to add multiple different implementations of the same listener interface type.

Constructors

  • RedundantListenerException(String message) : Will throw exception with message.

Example

MockitoFramework.addListener(MockitoListener);

Solutions

If you are trying to add the listener but a listener of the same type was already added (and not removed) this method will throw RedundantListenerException. This is a safeguard to ensure users actually remove the listeners via removeListener. We do not anticipate the use case where adding the same listener type multiple times is useful.

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/RedundantListenerException.html

Know More

To know more about Junit, Mockito and exception solutions follow below links:

[Solved]org.mockito.exceptions.base.MockitoException


MockitoException  is RuntimeException raised by Mockito framework to emit an error either due to Mockito, or due to the User. Mockito throws exception in form of stacktrace with suggested solutions.

StackTrace for Application calls:

StackTraceElement[] Throwable.getStackTrace()

StackTrace with Mockito and API calls:

StackTraceElement[] getUnifilteredStackTrace()

Constructors

  • MockitoException(String message) : Will throw exception with message.
  • MockitoException(String message, Throwable T) : Will throw exception with message and stacktrace.

Mockito Exception Subclasses

MockitoException Hierarchy
MockitoException Hierarchy

Example

In below example , using OngoingStubbing on mock object of Map interface where setting stub object for get() method which accept any input String and return response as String as set in thenReturn() method.

import static org.mockito.Matchers.anyString;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import java.util.Map;

import org.junit.Assert;
import org.junit.Test;
import org.mockito.exceptions.base.MockitoException;
import org.mockito.stubbing.OngoingStubbing;

public class MockitoApplicationTester {

@Test
public void second_stubbing_throws_InCorrectUseOfAPI() throws Exception {
// Mock of Map interface
Map<String, String> map = mock(Map.class);

OngoingStubbing<String> mapOngoingStubbing = when(map.get(anyString()));
try {
mapOngoingStubbing.thenReturn("1st stubbing");
//This method will throw exception
mapOngoingStubbing.thenReturn("2nd stubbing");
Assert.assertEquals(map.get("Test"), "1st stubbing");
} catch (MockitoException e) {
StackTraceElement[] stacks = e.getStackTrace();
for (StackTraceElement stack : stacks) {
System.out.println(stack.getMethodName());
}

StackTraceElement[] ustacks = e.getUnfilteredStackTrace();
for (StackTraceElement stack : ustacks) {
System.out.println(stack.getMethodName());
}
throw e;

}
}

Output

org.mockito.exceptions.base.MockitoException:
Incorrect use of API detected here:
-> at com.facingissuesonit.mockito.MockitoTestExamples.MockitoApplicationTester.second_stubbing_throws_IndexOutOfBoundsException(MockitoApplicationTester.java:48)

You probably stored a reference to OngoingStubbing returned by when() and called stubbing methods like thenReturn() on this reference more than once.
Examples of correct usage:
when(mock.isOk()).thenReturn(true).thenReturn(false).thenThrow(exception);
when(mock.isOk()).thenReturn(true, false).thenThrow(exception);

at com.facingissuesonit.mockito.MockitoTestExamples.MockitoApplicationTester.second_stubbing_throws_IndexOutOfBoundsException(MockitoApplicationTester.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)<span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			></span>

Solutions

Above example is throwing MockitoException with message as “Incorrect use of API detected here”  because of thenReturn() method set two times value for single mock stub object. For solving above issue comment one of thenRetun() statement from try block.

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/base/MockitoException.html#getUnfilteredStackTrace()

Know More

To know more about Junit, Mockito and exception solutions follow below links:

[Solved] org.mockito.exceptions.misusing.WrongTypeOfReturnValue


WrongTypeOfReturnValue is RuntimeException and Subclass of MockitoException.  It throws when :

  1.  It might occurred because of wrongly written multi-threaded tests.
  2. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to stub spies with doReturn|Throw() family of methods. 

Constructors

  • WrongTypeOfReturnValue(String message) : Will throw exception with message.

Example

Below case to show you on what case Mockito will throw WrongTypeOfReturnValue .

import static org.mockito.Mockito.*;
import static org.junit.Assert.*;

import org.junit.Test;

public class NestedWhen {
public class Bar {
}

public class Foo {
Bar getBar() {
return new Bar();
}
}

public class Product {
Bar bar;

Product(Foo f) {
bar = f.getBar();
}
}

public class ProductService {
Foo foo;

ProductService(Foo f) {
foo = f;
}

Product produce() {
return new Product(foo);
}
}

@Test
public void nestedWhenTest() {
Foo mfoo = mock(Foo.class);
Product mpoo = mock(Product.class);
ProductService productService = spy(new ProductService(mfoo));
// throw WrongTypeOfReturnValue exception here!!!
when(productService.produce()).thenReturn(mpoo);
}
}

Output

org.mockito.exceptions.misusing.WrongTypeOfReturnValue:
NestedWhen$Product$$EnhancerByMockitoWithCGLIB$$4418933b cannot be returned by getBar()
getBar() should return Bar
***
If you're unsure why you're getting above error read on.
Due to the nature of the syntax above problem might occur because:
1. This exception *might* occur in wrongly written multi-threaded tests.
Please refer to Mockito FAQ on limitations of concurrency testing.
2. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to stub spies -
- with doReturn|Throw() family of methods. More in javadocs for Mockito.spy() method.

at com.facingissuesonit.mockito.MockitoTestExamples.NestedWhen.nestedWhenTest(NestedWhen.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)

Solutions

Here above code is throwing this exception because spy execute the real code by nature, so when calling “productService.produce()” the expression is actually executed and return a real Product. The constructor of Product takes the constructor arg “foo” which is a mock and it executes “f.getBar()”. This invocation is recorded by mockito because this “foo” instance is a mock.

Then when you want to return “mpoo”, mockito raises the exception WrongTypeOfReturnValue saying that the recorded invocation “foo.getBar()” cannot return a Product.

If you want to mock a partial mock, which you should avoid if possible. You need to use the following style for spies, this way Mockito can tell the spy instance to only record the invocation.

doReturn(mpoo).when(productService).produce();

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/WrongTypeOfReturnValue.html

Know More

To know more about Junit, Mockito and exception solutions follow below links:

 

[Solved] org.mockito.exceptions.misusing.InvalidUseOfMatchersException


InvalidUseOfMatchersException is RuntimeException and subclass of MockitoException. It throws when trying to push behavior on object which is not mock.

Constructors

  • InvalidUseOfMatchersException() : Will throw exception.
  • InvalidUseOfMatchersException(String message) : Will throw exception with message.

Example

Here in below example mock Map interface and creating stub for get method to return fixed String for any type of String elements.


import static org.mockito.Matchers.anyString;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import java.util.HashMap;
import java.util.Map;

import org.junit.Assert;
import org.junit.Test;

public class MockitoApplicationTester {

@Test
public void second_stubbing_throws_InCorrectUseOfAPI() throws Exception {
// Mock of Map interface
Map<String, String> mapMock = mock(Map.class);
Map<String, String> mapReal = new HashMap<String, String>();

//Issue is here because performing argument matcher without mock object
when(mapReal.get(anyString())).thenReturn("1st stubbing");

//Correct statement
when(mapMock.get(anyString())).thenReturn("1st stubbing");

Assert.assertEquals(mapMock.get("Test"), "1st stubbing");

}

}

Output


org.mockito.exceptions.misusing.InvalidUseOfMatchersException:
Misplaced argument matcher detected here:

-> at com.facingissuesonit.mockito.MockitoTestExamples.MockitoApplicationTester.second_stubbing_throws_InCorrectUseOfAPI(MockitoApplicationTester.java:22)

You cannot use argument matchers outside of verification or stubbing.
Examples of correct usage of argument matchers:
when(mock.get(anyInt())).thenReturn(null);
doThrow(new RuntimeException()).when(mock).someVoidMethod(anyObject());
verify(mock).someMethod(contains("foo"))

Also, this error might show up because you use argument matchers with methods that cannot be mocked.
Following methods *cannot* be stubbed/verified: final/private/equals()/hashCode().
Mocking methods declared on non-public parent classes is not supported.

at com.facingissuesonit.mockito.MockitoTestExamples.MockitoApplicationTester.second_stubbing_throws_InCorrectUseOfAPI(MockitoApplicationTester.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)

Solutions

Here in above code is throwing this exception because using real object to create stub that’s what throwing “InvalidUseOfArgumentMatchersException“. To fix above this comment out wrong statement and execute again.

This exception can occurred by others ways also:

  1. This error might show up because you use argument matchers with methods that cannot be mocked.
  2. Stubbed and verified method can be used on final/private/equals()/hashCode() methods.
  3. Mocking methods declared on non-public parent classes is not supported.

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/InvalidUseOfMatchersException.html

Know More

To know more about Junit, Mockito and exception solutions follow below links:

[Solved] org.mockito.exceptions.misusing.MissingMethodInvocationException


MissingMethodInvocationException is RuntimeException and subclass of MockitoException. It generally throws when:

  1. It might occurs when() requires an argument which has to be ‘a method call on a mock. For example:                when(mock.getArticles()).thenReturn(articles);
  2. You try to stubbed/verified either of: final/private/equals()/hashCode() methods.
  3. Mocking methods declared on non-public parent classes is not supported.
  4. Inside when() you don’t call method on real object always call from mock or spy.

Constructors

  • MissingMethodInvocationException(String message) : Will throw exception with message.

Example

To complete example follow link Mockito + JUnit Tutorial

import static org.mockito.Mockito.spy;

import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;

import static org.mockito.Mockito.*;
//@RunWith attaches a runner with the test class to initialize the test data
@RunWith(org.mockito.runners.MockitoJUnitRunner.class)
public class MathApplicationTestrSpy {
private CalculatorService calcService;

@Before
public void setUp(){
Calculator calculator = new Calculator();
calcService = spy(calculator);
//Issue is here because using actual object
when(calculator.add(20.0,10.0)).thenReturn(30.0);
}

@Test
public void testAdd(){
Assert.assertEquals(calcService.add(20.0, 10.0),30.0,0);
}

}

Output

org.mockito.exceptions.misusing.MissingMethodInvocationException:
when() requires an argument which has to be 'a method call on a mock'.
For example:
when(mock.getArticles()).thenReturn(articles);

Also, this error might show up because:
1. you stub either of: final/private/equals()/hashCode() methods.
Those methods *cannot* be stubbed/verified.
Mocking methods declared on non-public parent classes is not supported.
2. inside when() you don't call method on mock but on some other object.

at com.facingissuesonit.mockito.MockitoTestExamples.MathApplicationTestrSpy.setUp(MathApplicationTestrSpy.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)

Solutions

Here in above example trying stub on real object instead of mock and spy object. To solve this issue update code as below. For complete example please refer Mockito + JUnit TutorialMockito + JUnit Tutorial.


@Before
public void setUp(){
Calculator calculator = new Calculator();
calcService = spy(calculator);
//Issue is here because using actual object
//when(calcService.add(20.0,10.0)).thenReturn(30.0);

//Used Spy object
when(calculator.add(20.0,10.0)).thenReturn(30.0);
}

References

https://static.javadoc.io/org.mockito/mockito-core/2.6.5/org/mockito/exceptions/misusing/MissingMethodInvocationException.html

Know More

To know more about Junit, Mockito and exception solutions follow below links: