Setting up the IDE

You can set up the SDNC IDE by following instructions from Setting Up Your Development Environment.

...

Unit Testing

It is recommend to use Junit4 and Mockito to write the junit tests.

Add Dependency to POM File

Add Junit and mockito dependencies as the following to the pom.xml if they are not already there.

Definition of Good Unit Test

Before start writing unit test, it's important that there's a common definition of what a good unit test is. 

From the official site of Roy Osherove’s book The Art of Unit Testing: 

A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.

In SDN-C project, the unit of work is being defined as Java Method and a "good" Unit Test:

• Is fully automated, integrated with the build process, executes fast, and can be run in any order.
• Executes  a specific service flow through a Java method with a known expected result based on the input parameters provides.
• Executes in isolation and doesn't interact with any external methods.
• Executes in memory and does not interact with any external systems, files or databases.
• Consistently return the same result and the result can be trusted.  It's Reliable, Repeatable, and Deterministic.

Unit Test Best Practices

• Arrange, Act, and Assert
  • Arrange everything you need for the Unit Test.
  • Act invokes the method under test and captures the results.
  • Assert represents the act of testing, it compares the actual result against the expected result. Assert(s) must be present to have a valid unit test.
• Assert The Results Are Correct
  
  • The Unit Test expects a result based on input and asserts it.
  • Simply testing that no exception has been thrown is not enough.
  • Avoid the common mistake of testing all of the functionality in one test case.
• Use a Naming Convention for Test Cases
  • Follow the shared naming convention when naming test cases.
  • Standards increase maintainability, readability and visibility.
• Avoid Test Interdependence
  • Each test should handle its own setup and tear down.
  • Do not maintain state information between test cases
• Keep Test Short, Sweet, and Visible
  • You want the test setup logic to be visible at a glance.
  • Unit test code should be concise
  • When a unit test fails you want to quickly and easily see what went wrong.

Unit Test Coverage

When determining what to unit test there are several key principles to keep in mind.

• Unit tests should verify business logic.
• Unit tests should be written that verify your code behaves as expected in "normal" scenarios as well as in more "unexpected" scenarios, like boundary conditions or error conditions (null or missing input values)
• Every time a bug is reported unit tests should be created or enhanced for the faulty code
• Do not unit test trivial code like getters and setters.
• Do not unit test external frameworks or application library functions, assume they work.
• Do not unit test database operations, assume they work when the database is available.

Java code coverage can be measured using an external tool such as JaCoCo which ONAP sonar build is using.

JUnit Test

JUnit is the unit test framework used for testing Java. It is recommend to use Junit4 and Mockito to write the junit tests.

JUnit Unit Test Naming Conventions

• The name of the test class should be the name of the class it is testing plus the word Test.
  • For example, class MyClass.java has test class MyClassTest.java.
• The name of a test should contain the name of the method being tested, scenario and expected output.
  • For example, test createCustomerWithNoNameRaisesException would be a test which is testing the method createCustomer, it tries to do so without providing a name so an exception should be raised.

Create JUnit Test in IntelliJ

This applies to both creating brand new JUnit Test class or navigating to existing test class to add new additions.

Open the class that you are going to write JUnit test for in IntelliJ.

In anywhere of this class editor, do Ctrl+Shift+T or right click to bring up right click menu, then select Go To, then Test in the cascaded menu:

Image Added

This will bring up the Choose Test for... window as below.

Choose Create New Test... for creating brand new JUnit Test, or just choose the test class to go to the existing tests.

Image Added

When Create New Test... is selected, the Create Test window will be brough up:

Image Added

The test Class name is automatically generated and shown in the window. Ensure the Testing library is selected with JUnit4.

Select

• setUp and tearDown for automatically generated setUp and tearDown methods block for each test case set up and tear down.
• the methods under Generate test methods for to automatically generate test method block for that method.

Click OK button, once you completed your selection/set up in the Create Test window.

It will bring you to the edit page of the new test class.

Add Dependency to POM File

If the Junit and mockito dependencies are not in the module and its parent pom file, add them the module pom.xml file as the following:

<dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>${junit.version}</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.mockito</groupId>
 <artifactId>mockito-core</artifactId>
 <version>${mockito.version}</version>
 <scope>test</scope>
</dependency>

Mock Class Level Attributes

More about how to use Mockito can be found from Mockito Tutorial.

...

Sometimes you do want to set/get class level attributes to satisfy complex test code and still keep the test coverage in sonar achievable, Whitebox of package org.mockito.internal.util.reflectio could be used to do code reflection.

Issue

...

With Using PowerMockito

There are multiple advantages of using PowerMockito to easily write the junit test.

...