JUnit

What is JUnit? You need to remember the following points when answering this question:

► It is a software testing framework to for unit testing.

► It is written in Java and designed to test Java applications.

► It is an Open Source Software maintained by the JUnit.org community.

Answer from the JUnit FAQ:

JUnit is a simple, open source framework to write and run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include:

► Assertions for testing expected results

► Test fixtures for sharing common test data

► Test runners for running tests

JUnit was originally written by Erich Gamma and Kent Beck.

It doesn't matter if you run your JUnit tests from a command line, from an IDE, or from "ant", you must define your CLASSPATH settings correctly. Here is what recommended by the JUnit FAQ with some minor changes:

To run your JUnit tests, you'll need the following elemements in your CLASSPATH:

* The JUnit JAR file.

* Location of your JUnit test classes.

* Location of classes to be tested.

* JAR files of class libraries that are required by classes to be tested.

If attempting to run your tests results in a NoClassDefFoundError, then something is missing from your CLASSPATH.

If you are running your JUnit tests from a command line on a Windows system:

set CLASSPATH=c:Ajunit-4.4.jar;c:Btest_classes;

c:Btarget_classes;c:D3rd_party.jar

If you are running your JUnit tests from a command line on a Unix (bash) system:

export CLASSPATH=/A/junit-4.4.jar:/B/test_classes:

/C/target_classes:/D/3rd_party.jar

This interview question is to check if you know the basic rules about writing a JUnit test method:

* You need to mark the method as a JUnit test method with the JUnit annotation: @org.junit.Test.

* A JUnit test method must be a "public" method. This allows the runner class to access this method.

* A JUnit test method must be a "void" method. The runner class does not check any return values.

* A JUnit test should perform one JUnit assertion - calling an org.junit.Assert.assertXXX() method.

Here is a simple JUnit test method:

import org.junit.*;

...

@Test public void testHello() {

String message = "Hello World!";

Assert.assertEquals(12, message.length());

}

You should be able to answer this question by looking up the org.junit.Assert class API document. Here is a list of assertino methods supported by JUnit 4.4:

* assertEquals(expected, actual)

* assertEquals(message, expected, actual)

* assertEquals(expected, actual, delta)

* assertEquals(message, expected, actual, delta)

* assertFalse(condition)

* assertFalse(message, condition)

* assertNotNull(object)

* assertNotNull(message, object)

* assertNotSame(expected, actual)

* assertNotSame(message, expected, actual)

* assertNull(object)

* assertNull(message, object)

* assertSame(expected, actual)

* assertSame(message, expected, actual)

* assertTrue(condition)

* assertTrue(message, condition)

* fail()

* fail(message)

* failNotEquals(message, expected, actual)

* failNotSame(message, expected, actual)

* failSame(message)

"@SuiteClasses" is a class annotation defined in JUnit 4.4 in org.junit.runners.Suite.SuiteClasses. It allows you to define a suite class as described in the previous question.

By the way, the API document of JUnit 4.4 has a major typo for the org.junit.runners.Suite class (Suite.html).

Using Suite as a runner allows you to manually build a suite containing tests from many classes. It is the JUnit 4 equivalent of the JUnit 3.8.x static Test suite() method. To use it, annotate a class with @RunWith(Suite.class) and @SuiteClasses(TestClass1.class, ...). When you run this class, it will run all the tests in all the suite classes.

"@SuiteClasses(TestClass1.class, ...)" should be changed to "@Suite.SuiteClasses({TestClass1.class, ...})".

Someone provided wrong information on build test suite in JUnit 4.4. Do not follow this:

JUnit provides tools to define the suite to be run and to display its results. To run tests and see the results on the console, run:

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.

Here is how the JUnit FAQ answers this question:

Debuggers are commonly used to step through code and inspect that the variables along the way contain the expected values. But stepping through a program in a debugger is a manual process that requires tedious visual inspections. In essence, the debugging session is nothing more than a manual check of expected vs. actual results. Moreover, every time the program changes we must manually step back through the program in the debugger to ensure that nothing broke.

It generally takes less time to codify expectations in the form of an automated JUnit test that retains its value over time. If it's difficult to write a test to assert expected values, the tests may be telling you that shorter and more cohesive methods would improve your design.

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.