TechyPages | Thinking in Solutions...!!!: Java

Writing Parameterized Test Cases in Junit

Many times we want to execute the same test case with different input and expectations. Instead of writing each test separately, it is much better to abstract the actual test into a class and inject input values and expected results into the test class. Junit4 provides Parametrized test, which is a standard solution to achieve this.

Let’s write a simple square() method to return square of a number. We’ll consider this square() method for writing our Parametrized test case:

package blog.techypages.junit.test;

/**
 * Utility class to support various mathematical functions.
 * 
 * @author abhishek
 *
 */
public class MathUtils {
    
    /**
     * Returns square of a number
     * @param number
     * @return
     */
    public static int square(int number){
        return number*number;
    }

}

To write Parametrized test cases a test class should satisfy following conditions:
1. Test class should be annotated with @RunWith(Parameterized.class) annotation.
2. Test class should have a static public method annotated with @Parameters annotation and returning a collection of test data elements (which in turn are stored in an array).
3. Test class should have a single constructor which accepts test data elements from the previously mentioned array and inject into object appropriate states.

When running a parametrized test class, a new test class is created for the cross-product of the test methods and the test data elements. It means for a test class if there is 1 test case and 5 input data then there will be total 5(1*5) instances of parameterized test class with their own set of input data.

Let’s write Parameterized test to test square() method for inputs [0,5] and their corresponding expectations.

package blog.techypages.junit.test;

import static org.junit.Assert.assertEquals;

import java.util.Arrays;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

/**
 * Parameterized test case.
 * 
 * @author abhishek
 *
 */
@RunWith(Parameterized.class)
public class SquareTest {

    @Parameters(name = "Test#{index}: square[{0}]={1}")
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[][] { 
                 {0, 0}, {1, 1}, {2, 4}, {3, 9}, {4, 16}, {5, 25}
           });
    }
    
    private int input;
    private int expected;
    
    public SquareTest(int input, int expected) {
        this.input = input;
        this.expected = expected;
    }

    @Test
    public void testSquare() {
        System.out.println("Test Case Instance: " + this);
        assertEquals(expected, MathUtils.square(input));
    }

}

Result:

Console Prints:

Test Case Instance: blog.techypages.junit.test.SquareTest@2ca6d51e
Test Case Instance: blog.techypages.junit.test.SquareTest@2aca0115
Test Case Instance: blog.techypages.junit.test.SquareTest@340d1fa5
Test Case Instance: blog.techypages.junit.test.SquareTest@4998a455
Test Case Instance: blog.techypages.junit.test.SquareTest@444cee32
Test Case Instance: blog.techypages.junit.test.SquareTest@16aa37a6

It is clearly evident from the console prints that there are total 6(1 test-case*6 input) instances of SqaureTest class.

Identify Individual Test Case
In order to easily identify the individual test cases in a Parameterized test, you may provide a name using the @Parameters annotation. This name is allowed to contain placeholders that are replaced at runtime:

1. {index} : the current parameter index
2. {0}, {1}, … : the first, second, and so on, parameter value

In our example we named the test case as "Test#{index}: square[{0}]={1}". Actual test names can be easily viewed in the Result snap.

Writing Parameterized test is pretty simple and useful to run the same test for various inputs.

Hope this article helped. Happy learning... :)

20:42
0 Comments

Creating temporary files or folders in Junit

Java

Numerous times we write Junit tests where we need to create temporary files and folders for executing the testcase. Usually, we create temporary folder at some physical location and write temporary files in it. Major pain in this approach is that we need to take care of creation and cleanup of all such files during the test lifecycle.

Junit4 comes with special Rule TemporaryFolder which automatically takes care of all such things. It creates the temp folder when a test starts and deletes the temp folder when the test finishes. It does this for every test method in the class. It will always clean up the files, whether the test passes, fails, or throws an exception.

Under the hood, TemporaryFolder uses the File.createTempFile() method to create the folder, so it's storing the folder in operating system's temp folder. It also assigns a unique name to the folder, so if the JVM crashes and TemporaryFolder does not clean up your files, the results of next test run will not be skewed by the files from the previous run.

Let’s see how it works:

package blog.techypages.junit.test;

import java.io.File;
import java.io.IOException;

import org.apache.commons.io.FileUtils;
import org.junit.Assert;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;

import blog.techypages.rule.RepeatRule;

/**
 * Class to check some of the usage of @see TemporaryFolder
 * 
 * @author abhishek
 *
 */
public class TemporaryFolderTest {
    @Rule
    public RepeatRule repeat = new RepeatRule(10);
    
    @Rule
    public TemporaryFolder tempFolder = new TemporaryFolder();

    @Test
    public void sampleTest() throws IOException {
        String writeString = "The quick brown fox jumps over the lazy dog.";
        
        // 1. Create a temp file.
        File tmpFile = tempFolder.newFile();
        System.out.println("Path: " + tmpFile.getAbsolutePath());

        // 2. Write writeString to this temp file.
        FileUtils.writeStringToFile(tmpFile, writeString);

        // 3. Read content of the temp file
        String readString = FileUtils.readFileToString(tmpFile);

        // 4. Verify: readString and writeString should be equal.
        Assert.assertEquals(writeString, readString);
    }

}

Output:

Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit17809417054081844.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit744343614217417992.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit5848675023725375369.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit3428415497682180161.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit7729225341687093633.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit8396781193866390009.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit7982918886982845418.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit986976126465928150.tmp
Path: C:\Users\ABHISH~1\AppData\Local\Temp\junit8242036959618829704\junit7979718795863279044.tmp

Note: It’s clearly evident from the output that on each repetition newFile() creates a new file within the temporary directory with a random file name[If a file name is not passed into the method, then it will generate a random file name]. Here, we used RepeatRule(10) to repeat the same testcase 10 times. For more information on RepeatRule, please read the previous post “Repeating a test case in Junit”.

Now after the test execution, let’s do a quick look up for the temp folder "junit8242036959618829704" in the system’s temp folder to see whether it exists or not:

C:\Users\ABHISH~1\AppData\Local\Temp>ls | grep "junit8242036959618829704"

C:\Users\ABHISH~1\AppData\Local\Temp>

You can see that the temp folder "junit8242036959618829704" has been cleaned up by TemporaryFolder.

It’s really very useful feature of Junit, which takes out the pain involved with temp files management in unit testing.

Hope this article helped. Happy learning... :)

17:03
1 Comments

Repeating a test case in Junit

Java

Many times we need to create Junit tests which needs to be repeated over and over (may be with different data set). Many of us did this by writing custom Runner or sometimes using parameterized test.

Junit4 comes with @Rule, which can be used for repeating a testcase. Actually, rules are used to add additional functionality which applies to all tests within a test class, but in a more generic way. Using @Rule for such a requirement is preferable because it does things in a more clean way. Moreover by using @Rule we still has option to use pretty useful runners like @RunWith(PowerMockRunner.class) etc.

Let’s create a simple Rule to repeat a test case to ‘N’ number of times:

package blog.techypages.rule;

import org.junit.rules.TestRule;
import org.junit.runner.Description;
import org.junit.runners.model.Statement;

/**
 * Rule class to be repeat the same test case over and over.
 * 
 * @author abhishek
 *
 */
public class RepeatRule implements TestRule {
    private int count;
    
    public RepeatRule(int count) {
        this.count = count;
    }
    
    @Override
    public Statement apply(final Statement base, Description description) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                for (int i = 0; i < count; i++) {
                    base.evaluate();
                }
            }
        };
    }

}

Let’s make a quick testcase and see how it works:

package blog.techypages.rule;

import org.junit.Rule;
import org.junit.Test;

/**
 * Class to demonstrate @see RepeatRule usage.
 * 
 * @author abhishek
 *
 */
public class RepeatTest {
    @Rule
    public RepeatRule rule = new RepeatRule(10);
    private int counter = 0;

    @Test
    public void test() {
        System.out.println(counter++);
    }

}

Output:

It’s really easy and useful feature of Junit. Use it next time and you will find it a great help.

Hope this article helped. Happy learning... :)

09:00
3 Comments

Correct way to check empty string in JAVA

Java

In our day-to-day programming activities, we usually come across multiple scenarios where we need to check whether a string is empty or not.

There are multiple ways to do this check in Java:

equals method: str.equals(“”)
length method: str.length() == 0 //recommended
isEmpty method [From Java 1.6 onward]: str.isEmpty() //recommended

The recommended way for empty string check is length() or isEmpty() method. We should never use equals(“”) for such a simple requirement.

Let’s have a look on the source code of String class to understand why we should use isEmpty/length:

length() method:

public int length() {
   return count;
}

isEmpty() method:

public boolean isEmpty() {
   return count == 0;
}

equals() method:

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = count;
        if (n == anotherString.count) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = offset;
            int j = anotherString.offset;
            while (n-- != 0) {
                if (v1[i++] != v2[j++])
                    return false;
            }
            return true;
        }
    }
    return false;
}

If we observe the source code of the above three methods provided by String class, it is very clear that length() is simply a getter method and returns length of the String. It’s obvious that any String having length 0 is always an empty string and so, the following code is able to detect whether the string is empty or not:

str.length() == 0;

The same reason holds behind using isEmpty() method. Moreover this method seems much verbose by its signature itself.

On the other hand, if we take a look on equals method, it seems to be relatively heavyweight. It does a lot of computation and consumes relatively more CPU cycles for the same operation. So, simply for such a basic check, using equals() method will result in lot of waste of CPU cycles.

Do share your thoughts.
Hope this article helped. Happy learning... :)

05:42
2 Comments

Writing Parameterized Test Cases in Junit

Creating temporary files or folders in Junit

Repeating a test case in Junit

Correct way to check empty string in JAVA

About me

Follow Us

Labels

Recent Posts

Blog Archive