Testing is the process of checking the functionality of the application whether it is working as per requirements.

Unit testing is the testing of single entity (class or method). Unit testing is very essential to every software company to give a quality product to their customers.

Executing the test cases manually without any tool support is known as manual testing.

Taking tool support and executing the test cases by using automation tool is known as automation testing.

Following are the disadvantages of manual testing −

1. Time consuming and tedious − Since test cases are executed by human resources so it is very slow and tedious.

2. Huge investment in human resources − As test cases need to be executed manually so more testers are required in manual testing.

3. Less reliable − Manual testing is less reliable as tests may not be performed with precision each time because of human errors.

4. Non-programmable − No programming can be done to write sophisticated tests which fetch hidden information.

Following are the advantages of automated testing −

1. Fast − Automation runs test cases significantly faster than human resources.

2. Less investment in human resources − Test cases are executed by using automation tool so less tester are required in automation testing.

3. More reliable − Automation tests perform precisely same operation each time they are run.

4. Programmable − Testers can program sophisticated tests to bring out hidden information.

JUnit is a Regression Testing Framework used by developers to implement unit testing in Java and accelerate programming speed and increase the quality of code.

Following are the important features of JUnit −

1. It is an open source framework.

2. Provides Annotation to identify the test methods.

3. Provides Assertions for testing expected results.

4. Provides Test runners for running tests.

5. JUnit tests can be run automatically and they check their own results and provide immediate feedback.

6. JUnit tests can be organized into test suites containing test cases and even other test suites.

7. JUnit shows test progress in a bar that is green if test is going fine and it turns red when a test fails.

A Unit Test Case is a part of code which ensures that the another part of code (method) works as expected. To achieve those desired results quickly, test framework is required .JUnit is perfect unit test framework for java programming language.

A formal written unit test case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a postcondition.

There must be at least two unit test cases for each requirement: one positive test and one negative test. If a requirement has sub-requirements, each sub-requirement must have at least two test cases as positive and negative.

Tests are written before the code during development in order to help coders write the best code.

Debugging the code using system.out.println() will lead to manual scanning of the whole output every time the program is run to ensure the code is doing the expected operations. Moreover, in the long run, it takes lesser time to code JUnit methods and test them on class files.

Follow the steps below −

1. Download the latest version of JUnit, referred to below as junit.zip.

2. Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%.

3. Add JUnit to the classpath −

set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar
            

• Test the installation by running the sample tests distributed with JUnit (sample tests are located in the installation directory directly, not the junit.jar file). 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.

Reporting multiple failures in a single test is generally a sign that the test does too much and it is too big a unit test. JUnit is designed to work best with a number of small tests. It executes each test within a separate instance of the test class. It reports failure on each test.

JUnit 3.7 deprecated assert() and replaced it with assertTrue(), which works exactly the same way. JUnit 4 is compatible with the assert keyword. If you run with the -ea JVM switch, assertions that fail will be reported by JUnit.

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 for unit testing server-side java code.

JUnit Framework can be easily integrated with either of the followings −

1. Eclipse
2. Ant
3. Maven

JUnit test framework provides following important features −

1. Fixtures
2. Test suites
3. Test runners
4. JUnit classes

Fixture is a fixed state of a set of objects used as a baseline for running tests. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable. It includes following methods −

1. setUp() method which runs before every test invocation.

2. tearDown() method which runs after every test method.

Test suite means bundle a few unit test cases and run it together. In JUnit, both @RunWith and @Suite annotation are used to run the suite test.

Test runner is used for executing the test cases.

JUnit classes are important classes which are used in writing and testing JUnits. Some of the important classes are −

• Assert − It contains a set of assert methods.

• TestCase − It contains a test case defines the fixture to run multiple tests.

• TestResult − It contains methods to collect the results of executing a test case.

• TestSuite − It is a Composite of Tests.

Annotations are like meta-tags that you can add to you code and apply them to methods or in class. The annotation in JUnit gives us information about test methods, which methods are going to run before & after test methods, which methods run before & after all the methods, which methods or class will be ignore during execution.

Follow the steps below −

• Set the CLASSPATH

• Invoke the runner −

java org.junit.runner.JUnitCore 
            

This class provides a set of assertion methods useful for writing tests. Only failed assertions are recorded.

A TestResult collects the results of executing a test case. It is an instance of the Collecting Parameter pattern. The test framework distinguishes between failures and errors. A failure is anticipated and checked for with assertions. Errors are unanticipated problems like an ArrayIndexOutOfBoundsException.

A TestSuite is a Composite of Tests. It runs a collection of test cases.

The Test annotation tells JUnit that the public void method to which it is attached can be run as a test case.

Several tests need similar objects created before they can run. Annotating a public void method with @Before causes that method to be run before each Test method.

If you allocate external resources in a Before method you need to release them after the test runs. Annotating a public void method with @After causes that method to be run after the Test method.

Annotating a public static void method with @BeforeClass causes it to be run once before any of the test methods in the class.

This will perform the method after all tests have finished. This can be used to perform clean-up activities.

Following are some of the usefulness of @Ignore annotation −

You can easily identify all @Ignore annotations in the source code, while unannotated or commented out tests are not so simple to find.

There are cases when you can't fix a code that is failing, but you still want to method to be around, precisely so that it does not get forgotten. In such cases @Ignore makes sense.

Following is how the JUnit execution procedure works −

1. First of all method annotated as @BeforeClass execute only once.

2. Lastly, the method annotated as @AfterClass executes only once.

3. Method annotated as @Before executes for each test case but before executing the test case.

4. Method annotated as @After executes for each test case but after the execution of test case.

5. In between method annotated as @Before and method annotated as @After each test case executes.

The test cases are executed using JUnitCore class. JUnitCore is a facade for running tests. It supports running JUnit 4 tests, JUnit 3.8.x tests, and mixtures.

Junit provides a handy option of Timeout. If a test case takes more time than specified number of milliseconds then Junit will automatically mark it as failed. The timeout parameter is used along with @Test annotation.

JUnit provides a option of tracing the Exception handling of code. You can test if a code throws desired exception or not. The expected parameter is used along with @Test annotation as follows − @Test(expected)

Junit 4 has introduced a new feature Parameterized tests. Parameterized tests allow developer to run the same test over and over again using different values.

There are five steps, that you need to follow to create Parameterized tests−

1. Annotate test class with @RunWith(Parameterized.class).

2. Create a public static method annotated with @Parameters that returns a Collection of Objects (as Array) as test data set.

3. Create a public constructor that takes in what is equivalent to one "row" of test data.

4. Create an instance variable for each "column" of test data.

5. Create your tests case(s) using the instance variables as the source of the test data.

6. The test case will be invoked once per each row of data. Let's see Parameterized tests in action.

Fixtures is a fixed state of a set of objects used as a baseline for running tests. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable. It includes −

• setUp() method which runs before every test invocation.

• tearDown() method which runs after every test method.

Compiling a JUnit test class is like compiling any other Java classes. The only thing you need watch out is that the JUnit JAR file must be included in the classpath.

If a JUnit test method is declared as "private", it compiles successfully. But the execution will fail. This is because JUnit requires that all test methods must be declared as "public".

When a method is declared as "protected", it can only be accessed within the same package where the class is defined. Hence to test a "protected" method of a target class, define your test class in the same package as the target class.

When a method is declared as "private", it can only be accessed within the same class. So there is no way to test a "private" method of a target class from any test class. Hence you need to perform unit testing manually. Or you have to change your method from "private" to "protected".

If a JUnit test method is declared to return "String", the compilation will pass ok. But the execution will fail. This is because JUnit requires that all test methods must be declared to return "void".

Yes you can test using main() method. One obvious advantage seems to be that you can whitebox test the class. That is, you can test the internals of it (private methods for example). You can't do that with unit-tests. But primarily the test framework tests the interface and the behavior from the user's perspective.

No. We need not write an independent test class for every class that needs to be tested. If there is a small group of tests sharing a common test fixture, you may move those tests to a new test class.

The test runner holds strong references to all Test instances for the duration of the test execution. This means that for a very long test run with many Test instances, none of the tests may be garbage collected until the end of the entire test run. Explicitly setting an object to null in the tearDown() method, for example, allows it to be garbage collected before the end of the entire test run.

In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is impractical or impossible to incorporate into a unit test.

The common coding style for testing with mock objects is to −

1. Create instances of mock objects.
2. Set state and expectations in the mock objects.
3. Invoke domain code with mock objects as parameters.
4. Verify consistency in the mock objects.

Following are the JUnit extensions −

1. Cactus

2. JWebUnit

3. XMLUnit

4. MockObject

Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters). The intent of Cactus is to lower the cost of writing tests for server-side code. It uses JUnit and extends it. Cactus implements an in-container strategy, meaning that tests are executed inside the container.

Cactus Ecosystem is made of several components −

1. Cactus Framework is the heart of Cactus. It is the engine that provides the API to write Cactus tests.

2. Cactus Integration Modules are front ends and frameworks that provide easy ways of using the Cactus Framework (Ant scripts, Eclipse plugin, Maven plugin).

WebUnit is a Java-based testing framework for web applications. It wraps existing testing frameworks such as HtmlUnit and Selenium with a unified, simple testing interface to allow you to quickly test the correctness of your web applications.

JWebUnit provides a high-level Java API for navigating a web application combined with a set of assertions to verify the application's correctness. This includes navigation via links, form entry and submission, validation of table contents, and other typical business web application features.

The simple navigation methods and ready-to-use assertions allow for more rapid test creation than using only JUnit or HtmlUnit. And if you want to switch from HtmlUnit to other plugins such as Selenium (available soon), there is no need to rewrite your tests.

XMLUnit provides a single JUnit extension class, XMLTestCase, and a set of supporting classes.

Supporting classes allow assertions to be made about−

1. The differences between two pieces of XML (via Diff and DetailedDiff classes).

2. The validity of a piece of XML (via Validator class).

3. The outcome of transforming a piece of XML using XSLT (via Transform class).

4. The evaluation of an XPath expression on a piece of XML (via classes implementing the XpathEngine interface).

5. Individual nodes in a piece of XML that are exposed by DOM Traversal (via NodeTest class).