jUnit && Mockito code-driven unit testing framework

Junit – 4, 4++, 5

Test:- it is the validation of functional and nonfunctional requirements before it is shipped to a customer.

Unit testing means performing the sanity check of code.

Sanity check is a basic test to quickly evaluate whether the result of a calculation can possibly be true.

It is a simple check to see whether the produced material is coherent.

Use Case:-

It's a common practice to unit test the code using print statements in the main method or by executing the application.

Neither of them is the correct approach.

Mixing up production code with tests is not a good practice. Testing logic in the production code is a code smell, though it doesn't break the code under the test. However, this increases the complexity of the code and can create severe maintenance problem or cause system failure if anything gets misconfigured.

Print statements or logging statements are executed in the production system and print unnecessary information. They increase execution time and reduce code readability. Also, junk logging information can hide a real problem, for instance, you may overlook a critical deadlock or a hung thread warning because of excessive logging of junk.

Unit testing is a common practice in test-driven development (TDD). TDD is a development approach where the production code is written only to satisfy a test, and the code is refactored to improve its quality. Basically, It offers test-first development.

In TDD, unit tests drive the design.

Java code can be unit tested using a code-driven unit testing framework.

The following are a few of the available code-driven unit testing frameworks for Java:

• SpryTest

• Jtest

• JUnit

• TestNG

JUnit is the most popular and widely used unit testing framework for Java.

Junit – code-driven unit testing framework for java, It is an annotation-based, flexible framework.

Apparently, TestNG is cleaner than JUnit, but JUnit is far more popular than TestNG.

JUnit has a better mocking framework support such as Mockito, which offers a custom JUnit 4 runner.

Exploring annotations

The @Test annotation represents a test.

Any public method can be annotated with the @Test annotation with @Test to make it a test method. There's no need to start the method name with test.

We need data to verify a piece of code. For example, if a method takes a list of students and sorts them based on the marks obtained, then we have to build a list of students to test the method. This is called data setup.

JUnit 4 provides a @Before annotation. If we annotate any public void method of any name with @Before, then that method gets executed before every test execution. Similarly, any method annotated with @After gets executed after each test method execution.

JUnit 4 provides two more annotations:

@BeforeClass and @AfterClass.

They are executed only once per test class. The @BeforeClass and @AfterClass annotations can be used with any public static void methods. The @BeforeClass annotation is executed before the first test and the @AfterClass annotation is executed after the last test. The following example explains the annotation usage and the execution sequence of the annotated methods.

Verifying test conditions with Assertion

Assertion is a tool (a predicate) used to verify a programming assumption (expectation) with an actual outcome of a program implementation; for example, a programmer can expect that the addition of two positive numbers will result in a positive number. So, he or she can write a program to add two numbers and assert the expected result with the actual result.

The org.junit.Assert package provides static overloaded methods to assert expected and actual values for all primitive types, objects, and arrays.

The following are the useful assert methods:

assertTrue(condition)

assertFalse(condition)

assertNull

assertNotNull

assertEquals(string message, object expected, object

actual)

assertEquals(object expected, object actual) := i.equals(j) and not i == j . Hence, only the values are compared, not the references

assertEquals(primitive expected, primitive actual)

assertSame(object expected, object actual) := passes only when the expected object and the actual

object refer to the same memory location.

assertNotSame(object expected, object actual) := fails only when the expected object and the actual object refers to the same memory location.

if the actual value doesn't match the expected value, AssertionError is thrown.

Working with exception handling

an API needs three objects; if any argument is null, then the API should throw an exception. This can be easily tested. If the API doesn't throw an exception, the test will fail.

@Test(expected=RuntimeException.class)

public void exception() {

throw new RuntimeException();}

Exploring the @RunWith annotation

Junit 4++

Ignoring a test

@Test

@Ignore("John's holiday stuff failing")

public void when_today_is_holiday_then_stop_alarm() {

}

Executing tests in order

@FixMethodOrder(MethodSorters.NAME_ASCENDING)

public class TestExecutionOrder { ... }

Learning assumptions

Exploring the test suite

To run multiple test cases, JUnit 4 provides Suite.class and the @Suite.SuiteClasses annotation. This annotation takes an array (comma separated) of test classes.

@RunWith(Suite.class)

@Suite.SuiteClasses({ AssertTest.class, TestExecutionOrder.class, Assumption.class })

public class TestSuite {

}

Create a TestSuite class and annotate the class with @RunWith(Suite.class) .

This annotation will force Eclipse to use the suite runner instead of using the built-in runner.

Asserting with assertThat