JUnit Interview Questions And Answers - DoAnswers.com

JUnit is the de facto standard unit testing library for the Java language. JUnit 4 is the first significant release of this library in almost three years. It promises to simplify testing by exploiting Java 5's annotation feature to identify tests rather than relying on subclassing, reflection, and naming conventions. In this article, obsessive code tester Elliotte Harold takes JUnit 4 out for a spin and details how to use the new framework in your own work. Note that this article assumes prior experience with JUnit.

JUnit, developed by Kent Beck and Erich Gamma, is almost indisputably the single most important third-party Java library ever developed. As Martin Fowler has said, "Never in the field of software development was so much owed by so many to so few lines of code." JUnit kick-started and then fueled the testing explosion. Thanks to JUnit, Java code tends to be far more robust, reliable, and bug free than code has ever been before. JUnit (itself inspired by Smalltalk's SUnit) has inspired a whole family of xUnit tools bringing the benefits of unit testing to a wide range of languages. nUnit (.NET), pyUnit (Python), CppUnit (C++), dUnit (Delphi), and others have test-infected programmers on a multitude of platforms and languages.

However, JUnit is just a tool. The real benefits come from the ideas and techniques embodied by JUnit, not the framework itself. Unit testing, test-first programming, and test-driven development do not have to be implemented in JUnit, any more than GUI programming must be done with Swing. JUnit itself was last updated almost three years ago. Although it's proved more robust and longer lasting than most frameworks, bugs have been found; and, more importantly, Java has moved on. The language now supports generics, enumerations, variable length argument lists, and annotations--features that open up new possibilities for reusable framework design.

JUnit's stasis has not been missed by programmers who are eager to dethrone it. Challengers range from Bill Venners's Artima SuiteRunner to Cedric Beust's TestNG. These libraries have some features to recommend them, but none have achieved the mind or market share held by JUnit. None have broad out-of-the-box support in products like Ant, Maven, or Eclipse. So Beck and Gamma have commenced work on an updated version of JUnit that takes advantage of the new features of Java 5 (especially annotations) to make unit testing even simpler than it was with the original JUnit. According to Beck, "The theme of JUnit 4 is to encourage more developers to write more tests by further simplifying JUnit." Although it maintains backwards compatibility with existing JUnit 3.8 test suites, JUnit 4 promises to be the most significant innovation in Java unit testing since JUnit 1.0.

JUnit 4.4 stops using the "public static Test suite()" method to build a test suite class. It is now provides the org.junit.runners.Suite class and two annotations to help you to build test suite.

org.junit.runners.Suite - JUnit 4.4 runner class that runs a group of test classes.

org.junit.runner.RunWith - JUnit 4.4 class annotation that specify runner class to run the annotated class.

org.junit.runner.Suite.SuiteClasses - JUnit 4.4 class annotation that specify an array of test classes for the Suite.class to run.

The annotated class should be an empty class.

To run "@Suite.SuiteClasses" class, you can use the core runner: org.junit.runner.JUnitCore.

Here is a good example of "@Suite.SuiteClasses" class:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

// specify a runner class: Suite.class
@RunWith(Suite.class)

// specify an array of test classes
@Suite.SuiteClasses({
HelloTest.class,
ExpectedExceptionTest1.class,
ExpectedExceptionTest2.class,
UnexpectedExceptionTest1.class,
UnexpectedExceptionTest2.class}
)

// the actual class is empty
public class AllTests {
}

The Simple Object Access Protocol (SOAP) uses XML to define a protocol for the exchange of information in distributed computing environments. SOAP consists of three components: an envelope, a set of encoding rules, and a convention for representing remote procedure calls.

This is a common question in a job interview. You should answer it with these points:

A debugger is designed for manual debugging and manual unit testing, not for automated unit testing.
JUnit is designed for automated unit testing.
Automated unit testing requires extra time to setup initially. But it will save your time, if your code requires changes many times in the future.

It is possible to write a main() method in each class that need to be tested for unit testing. In the main() method, you could create test object of the class itself, and write some tests to test its methods.

However, this is not a recommended approach because of the following points:

Your classes will be cluttered with test code in main method. All those test codes will be packaged into the final product.
If you have a lots of classes to test, you need to run the main() method of every class. This requires some extra coding effort.
If you want the test results to be displayed in a GUI, you will have to write code for that GUI.
If you want to log the results of tests in HTML format or text format, you will have to write additional code.
If one method call fails, next method calls won?t be executed. You will have to work-around this.

If you start working on a project created by some other team in your organization, you may see an entirely different approach for testing. That will increase your learning time and things won?t be standard.
Above are some of the problems, which will be taken care of automatically if you use Junit. Junit provides a standard framework for writing your tests. It separates test code from project code, hence keeps everything clean.

No. It is a convention to start with one test class per class under test, but it is not necessary.

Test classes only provide a way to organize tests, nothing more. Generally you will start with one test class per class under test, but then you may find that a small group of tests belong together with their own common test fixture.[1] In this case, you may move those tests to a new test class. This is a simple object-oriented refactoring: separating responsibilities of an object that does too much.

Another point to consider is that the TestSuite is the smallest execution unit in JUnit: you cannot execute anything smaller than a TestSuite at one time without changing source code. In this case, you probably do not want to put tests in the same test class unless they somehow "belong together". If you have two groups of tests that you think you'd like to execute separately from one another, it is wise to place them in separate test classes.

[1] A test fixture is a common set of test data and collaborating objects shared by many tests. Generally they are implemented as instance variables in the test class.

First, download the latest version of JUnit, referred to below as junit.zip.
Then install JUnit on your platform of choice:
Windows
To install JUnit on Windows, follow these steps:
Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%.
Add JUnit to the classpath:
set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar

Unix (bash)
To install JUnit on Unix, follow these steps:
Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME.
Add JUnit to the classpath:
export CLASSPATH=$CLASSPATH:$JUNIT_HOME/junit.jar
(Optional) Unzip the $JUNIT_HOME/src.jar file.

Test the installation by running the sample tests distributed with JUnit. Note that the sample tests are located in the installation directory directly, not the junit.jar file. Therefore, make sure that the JUnit installation directory is on your CLASSPATH. Then simply type:

java org.junit.runner.JUnitCore org.junit.tests.AllTests
All the tests should pass with an "OK" message.

If the tests don't pass, verify that junit.jar is in the CLASSPATH.

To run JUnit tests from a command window, you need to check the following list:

1. Make sure that JDK is installed and the "java" command program is accessible through the PATH setting. Type "java -version" at the command prompt, you should see the JVM reports you back the version string.

2. Make sure that the CLASSPATH is defined as shown in the previous question.

3. Invoke the JUnit runner by entering the following command:

java org.junit.runner.JUnitCore

Often if a method doesn't return a value, it will have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.

There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

@Test
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
Another approach is to make use of MockObjects.

A related issue is to design for testing. For example, if you have a method that is meant to output to a file, don't pass in a filename, or even a FileWriter. Instead, pass in a Writer. That way you can pass in a StringWriter to capture the output for testing purposes. Then you can add a method (e.g. writeToFileNamed(String filename)) to encapsulate the FileWriter creation.

10. How do I test things that must be run in a J2EE container (e.g. servlets, EJBs)?

Refactoring J2EE components to delegate functionality to other objects that don't have to be run in a J2EE container will improve the design and testability of the software.
Cactus is an open source JUnit extension that can be used to test J2EE components in their natural environment.