Wednesday, 30 January 2013

JUnit: Automated testing in Java

Automated testing in Java

The 1 minute guide to JUnit

1 minute. We will get you using JUnit and automated testing in 1 minute.

This is not a JUnit manual. It is not a tutorial. This post is simply a starting point. We assume that you are using Eclipse as an IDE.

What is JUnit?

  • Automated testing that's 100% Java.
  • No cost, part of Java technology
  • It calls tests that you write yourself in Java. JUnit is a way of running tests that you have written.
  • It saves huge amounts of time and effort keeping your software tested with each change that you make.
  • Get the best benefit using JUnit in an IDE such as Eclipse.

JUnit structure 

Your JUnit should match your application. For each class in your application, you create a corresponding JUnit class. For each method in your applicaiton class, created one or more test methods in your JUnit class:

In the Application, for each: Create in JUnit:
Class Associated test class
Class method One or more test methods

For example, your application has a class HexEncode.java that contains a method:
public static String encodeString(String inp)
You would create a JUnit class as follows:

In the Application: Create in JUnit:
HexEncode.java HexEncodeTest.java
Method: encodeString public void testEncodeString()

Note
  • JUnit methods are of type public void with no parameters.
  • Put the word "Test" at the end of your JUnit class name.
  • put the word "test" in front of each method. If you don't JUnit will not run that method.
 You can create the methods setUp and tearDown. These JUnit calls before processing (setUp) and after processing (tearDown) the test methods in your JUnit class. For example, these are where you may want to connect to a database and close the database connection.

You can create other methods in your JUnit and use them internally. If they don't start with test they won't be called.

JUnit class definitions

A JUnit class imports junit.framework.TestCase and the class extends TestCase:
import junit.framework.TestCase;

public class MyAppClassTest extends TestCase {

Specifying success and failure

JUnit provides assert* methods, the most widely used being assertEquals. This is how the tests are implemented. You do whatever setup you need in your JUnit method first, then you assertEquals the expected result with the variable (or method return) that contains the real world result.

For example, to test encodeString above, we create the method testEncodeString in our HexEncodeTest class:

import junit.framework.TestCase;
public class HexEncodeTest extends TestCase {
    public void testhexEncodeTest() {        String enc=  ":42:72:61:64:20:A3:31:32:33:30";        String orig= "Brad £1230"; 
        assertEquals(enc, HexEncode.encodeString(orig));
               
    }

}
This then calls our application class's encodeString method and tests against the expected result (held in variable enc). If the two match, the test passes. If they are different, the test fails.

You can write as many test* methods as you want, JUnit will call them all. You can put as much Java coding into your methods as you want, sufficient to test all the expected actions and results from your application method.

Note: assertEquals is the essence of JUnit and takes any Java parameter type.

Common setup methods

The order of JUnits running cannot be guaranteed. You should always write your JUnit classes so that they are completely stand-alone. By this we mean that they set up all the data that they need from scratch. They do not depend on other tests having run (or not run) and if the test data is in a mess, it shouldn't matter, because the class must set up the data that it needs.
Likewise your test methods within those classes should also be stand-alone and able to be run in any order. They should not depend on other methods having run first and they should always set up the test data that they need completely within the method.
For this reason, you will almost certainly benefit from writing common "set up" and "clean up" methods, either within the JUnit class itself, or as a separate class the each JUnit class can use. This is especially useful for setting up test data in a database.

Creating JUnits in Eclipse

In Eclipse, open your project then click on File->New->JUnit Test Case.

Running JUnits in Eclipse

  • All tests: In Eclipse, open your project then right-click on the "test" folder. Then choose Run As->JUnit Test
  • One test class: Right-click the test class then choose: Run As->JUnit Test

Failed tests

Eclipse will show you the tests that fail in the Failure Trace pane. It displays the expected results and the real results. You can click on the line to jump to the test that failed.

JUnit as you develop

JUnit is there to save you time and effort. If you write your JUnits for the code that you are developing, as you develop the code:
  • The JUnits will test your code
  • Writing JUnits ensures that you understand the code requirements
  • Because testing seeks to find boundary, logical and exceptions errors, writing JUnits as you develop ensure that you develop complete code that handles errors and exceptions as well as being correct
The dividends in your efforts quickly stack up if you develop JUnits alongside your application code development.

Software releases

Never release software unless you have run the entire JUnit test suite successfully (see All tests above).

Real world bugs

If a bug in your code is discovered in the real world, you didn't put that test in your JUnits! You should immediately update your JUnits to test for that bug:
  • It will test your fix
  • It will protect you against that same bug re-appearing later

1 comment:

  1. Very useful article, thanks for sharing. You can easily control your company software with quality assurance service like http://www.nixsolutions.com/services/quality-assurance-services/ try to and I'm sure they can help you to solve your problems with your software.

    ReplyDelete