Explore topic-wise InterviewSolutions in .

Generics allows creating CLASSES, interfaces or methods that OPERATE with DIFFERENT data types at a time. In order to test Generic entities, we can test it for one or two datatypes for the LOGIC SINCE the datatype allocation are evaluated at compilation time for type-correctness.

It is generally not required to test private methods directly. Since they are private, it is assumed that they are called from public methods. If these methods are working as expected, then by extension it is considered that the private methods are working correctly. HOWEVER, we can explore how the private methods are tested using REFLECTION. 

LET us consider we have a public class Item with private method getItemName() as shown below:

Consider we have a test class ItemTest that tests this method as shown below:

In the above code, we see that we can test the private method by using getDeclaredMethod method of the Method class that belongs to reflection strategy. Since we know that the private methods cant be invoked directly, we can use the Method class object’s invoke() method and send the input parameters. Then as usual, we can compare the results with the expected and the actual methods.

JUnit is usually designed in a way that it deals with smaller tests and is capable of RUNNING each ASSESSMENT with a BOUNDARY of separate ANALYSIS. Due to this, it reports only the first failure on each test case attempt.

Following are some of the best PRACTICES that can be followed while coding to make the CODE more testable:

• Make USE of interfaces as a wrapper to IMPLEMENTATION classes. This helps testers to replace the class with mocks or stubs to TEST the module.
• Use dependency injection wherever needed instead of creating. new objects. This makes it easy for testing individual modules and also supply dependency in the test configuration.
• Avoid using static methods as that makes it difficult to test because they cannot be called polymorphically.

Yes, it is possible. @Test annotation provides a timeout parameter that takes value in MILLISECONDS in JUNIT that is USED for INSTRUCTING JUnit to pass or fail the test method based on execution time. For instance, if a test method has Test annotation as @Test(timeout=30), then it means that if the execution does not COMPLETE in 30ms, then the test case will be failed. This helps in verifying the SLA of the Java method.

The extent to which the SOURCE code is UNIT tested is called coverage. There are THREE types of coverage TECHNIQUES, they are:

• Statement coverage: This ensures that each statement/line in the source code is executed and tested.
• Decision coverage: This ensures that EVERY decision point that results in true or false is executed and run.
• Path coverage: This ensures that every possible route from a given point is run and tested.

We can PRESS Alt+Shift+X for RUNNING the test. We can also right-click on the PROJECT, select RUN As and then select JUnit Test. If the test METHOD needs to be rerun, then we can press Ctrl+F11.

The CODE cyclomatic complexity is calculated based on the number of DECISION POINTS of the code that contributes to different execution paths as shown in the image below:

This is why, higher the cyclomatic complexity, the more DIFFICULT is to attain the REQUIRED code coverage.

Hamcrest is a JUnit framework used to write matcher objects that provides ‘match’ rules DEFINITION in a declarative manner. They are used in UI validation, data filtering and for writing flexible unit TESTS. Hamcrest matches are used in the assertThat() method in JUnit. We can use one or more matchers within this assert method. Some of the matcher methods are as follows:

The order of execution of these annotations is as shown below:

Consider an example to see how to write test cases for asserting exceptions.

The method convertToUpperCase() defined in the ExceptionDemo class would throw an IllegalArgumentException if an empty string is passed as an input to the method.
Let us write unit test cases for asserting the exception thrown in the code. In JUnit, there are 3 different ways of achieving this and they are as follows:

try-catch idiom: We can use the try-catch block for asserting exception as shown below:

@Test expected annotation: 

Here we give the expected exception as value to the expected parameter of the @Test annotation as:@Test(expected = IllegalArgumentException.class)

When no exception is thrown by the target method under test, then we will GET the below MESSAGE:

Care has to be taken here while defining the expected Exception. We should not expect general Exception, RuntimeException or even a Throwable type of exceptions as that is a bad practice. If we do so, then there are chances that the code can throw an exception in other places and the test case can pass.

Here we cannot assert the message in the exception. The code snippet of the test method would be:

Junit @Rule:

The same example can be created using the ExceptedException rule. The rule must be a public field marked with @Rule annotation.

 In this approach, when the exception is not thrown, we will get:

The FIRST step is to SET the CLASSPATH with the library PATH. Then invoke the JUnit runner by running the command:

To run the test class VIA commandline, we would first have to compile the class. This can be done by running:

Then we can run the compiled test class using the console launcher of JUnit by running the following command:

If we use System.out.println() for DEBUGGING, then we would have to do a manual SCAN of the outputs every time program is executed to ensure that the output PRINTED is the expected output. Also, in the longer run, writing JUnit tests will be easier and will take lesser time. Writing test cases will be like an initial investment and then, LATER on, we can later AUTOMATICALLY test them on the classes.

For testing PROTECTED methods, the test CLASS should be DECLARED in the same package as that of the target class.

These are the annotations PRESENT in JUNIT 4. Methods annotated with @Before will be called and RUN before the execution of each test case. Methods annotated with @After will be called and executed after the execution of each test case. If we have 5 test cases in a JUnit CLASS, then the methods annotated with these two would be run 5 times. In JUnit 5, the annotations @Before and @After are renamed to @BeforeEach and @AfterEach for making it more readable.

We NEED to IGNORE test cases when we have certain functionalities that are not certain or they are under development. To wait for the completion of the code, we can AVOID running these test cases. In JUnit 4, we can achieve this by using @Ignore annotation over the test methods. In JUnit 5, we can do it using @DISABLED annotation over the test methods.

A standard unit test case comprises a known INPUT and an expected output. These two things need to be known before we run the test case. A known input is tested for a precondition and an expected output is tested by postcondition. Following are the best practices for writing unit test cases:

• For every method, we need to have at least two unit test cases - a positive test case and a negative test case.
• If there are sub-requirements for a requirement, then those sub-requirements should have their own positive and negative test cases.
• Each test case should be independent of other test cases. If we make a CHAIN of unit test cases, then it would not be possible for FINDING the root cause of the test case failures.
• Mock all the external services that are used by the modules under test. This is necessary because we do not want to unnecessarily debug our modules under test due to the failures of the external systems.
• Configuration settings need not be tested as they won’t be part of any unit code. Even if we want to inspect the configuration, then test WHETHER the loading code is working or not.
• The unit test cases should be named consistently and clearly. The names of the test cases should be dependent on the OPERATIONS that the test case would test.