Difference between revisions of "Better Exception Testing in ICE with J-Unit"

Latest revision as of 08:16, 9 July 2015

Better JUNIT Testing

In many developing software applications (including ICE), unit testing has become a vital role in developing reliable, safer, and more robust products. JUNIT is one of the tools that can be used to run unit and integration tests for Java-based applications in test-driven development. Below is an example of utilizing better methods for developing unit tests for handling Exceptions on tested objects with the testing tool.

Here is a sample exception try/catch statement within a JUnit test:

//A class that tests the operation
//StringToIntegerUtility.customStrToInt(String number)
@Test
public void checkStringToInteger() {
 
    //Local declaration
 
    int number;
    String number = "Not a number";
    boolean expectedFail = false;
 
    //Setup class
    StringToIntegerUtility utility = new StringToIntegerUtility();
 
    //Call operation with try/catch statement
    try {
        number = utility.customStrToInt(number);
    } catch (NumberFormatException e) {
        //We expect this to happen
        expectedFail = true;
    }
 
    //Test is valid if it failed
    assertTrue(expectedFail);
 
}

When the utility operation is called, there has to be a try/catch statement. Try/catch statements can clutter code and confuse some forms of unit testing. What can be done is to separate these specific exception unit tests into their own methods and have JUNIT check the exceptions. Below is a better way to handle the exceptions in a JUNIT test.

//A class that tests the operation
//StringToIntegerUtility.customStrToInt(String number)
@Test(expected=java.lang.NumberFormatException.class)
public void checkStringToInteger() throws NumberFormatException {
    //Local declaration
    int number;
    String number = "Not a number";
 
    //Setup class
    StringToIntegerUtility utility = new StringToIntegerUtility();
 
    //Call operation, and this operation should
    //throw an exception.
    number = utility.customStrToInt(number);
 
}

This method cuts down on some of the more excessive try/catch statements in unit testing. It also helps to modularize the codebase in unit testing by separating out the exception cases from other tests. The expected statement catches the exception when it is thrown. Nevertheless, there are some limitations to this method. For example, when the exception is thrown, the testing ends in that method. Thus, if one were to need to write more expansive tests that utilize many exceptions, there would need to be an individual method for each exception. Secondly, this can pose a problem for identifying messages in exceptions for generic Exception handling or classes with multiple types of references. The second issue can be resolved by using the thrown.expect(class) and thrown.expectMessage(String) from the JUnit API. These types of calls are declared within the method and not annotated.

Locations of Exceptions

There are many areas in ICE where native and customized exceptions are thrown and caught within the applications. Many of them are required by overloaded applications, while others are created to catch specific errors in ICE. Below is a list of the operations that throw and/or catch exceptions within ICE's general architecture. It will also mention if the error prints out a stack trace or not. If it does, it will mention whether or not the operation is handled within the method. Note that just printing a stack trace does not constitute an operation as "being handled". Returning false on a boolean method for a failed initialization of another method because of a try/catch statement is an example of "handling" an issue.

This is a table for exceptions caught within each method.

This is a table for a list of exceptions thrown within each method of each class. Usually when an exception is thrown, an issue is handled in a higher level operation/method. Therefore "handles error" does not apply here.

References

http://weblogs.java.net/blog/johnsmart/archive/2009/09/27/testing-exceptions-junit-47

http://kentbeck.github.com/junit/javadoc/4.10/org/junit/rules/ExpectedException.html