Tuesday, October 21, 2014

JUnit Parameterized and named tests

A relatively simple, working and complete example of JUnit Parameterized named tests.

Advantages of Parameterized in JUnit testing:

  • Re-use the same test methods over and over, just changing the parameters.
  • The method annotated by @Parameters could return a collection of data from a spreadsheet, database or hard-coded variable.
  • New naming mechanism lets you add a sensible label to each test to make it easy to identify the one that failed.
import static org.junit.Assert.assertEquals;

import java.util.Arrays;
import java.util.Collection;

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

@RunWith(Parameterized.class)
public final class MultiplicationParameterizedTest {

   private final int expectedResult;
   private final int firstNumber;
   private final int secondNumber;

   public MultiplicationParameterizedTest(final int theExpectedResult,
         final int theFirstNumber, final int theSecondNumber) {
      expectedResult = theExpectedResult;
      firstNumber = theFirstNumber;
      secondNumber = theSecondNumber;
   }

   @Parameters(name = "Multiplication test {index}: {0}={1}x{2}")
   public static Collection<Integer[]> numbersToBeMultiplied() {
      return Arrays.asList(new Integer[][] {
            { 10, 5, 2 },
            { 48, 6, 8 },
            { 1452, 33, 44 },
            { 1044, 87, 12 },
            { 135, 3, 45 },
            });
   }

   @Test
   public void sum() {
      final int actualResult = multiplyNumbers(firstNumber, secondNumber);
      assertEquals("Expected [" + firstNumber + " * " + secondNumber + " = "
            + expectedResult + "], not [" + actualResult + "]", expectedResult,
            actualResult);
   }

   public int multiplyNumbers(int a, int b) {
      int product = a * b;
      return product;
   }

}

Here is what the tests look like when they pass in Eclipse. It shows you useful the naming mechanism is.

Now I change the last test case just to show what a failure looks like.

@Parameters(name = "Multiplication test {index}: {0}={1}x{2}")
public static Collection numbersToBeMultiplied() {
   return Arrays.asList(new Integer[][] {
         { 10, 5, 2 },
         { 48, 6, 8 },
         { 1452, 33, 44 },
         { 1044, 87, 12 },
         { 13, 3, 45 },
         });
}

And in Eclipse, that failure looks like this:

You can still use setup and tear down methods:

@Before
public void setup() {
   System.out.println("Set up [" + firstNumber + " * " + secondNumber
         + " = " + expectedResult + "].");
}

@After
public void tearDown() {
   System.out.println("Tear down [" + firstNumber + " * " + secondNumber
         + " = " + expectedResult + "].");
}

Note that names feature was introduced in JUnit 4.11, which is the latest stable build at the time of writing (Tuesday 21 October 2014).

What about data from a spreadsheet with lots of columns?

I am thinking of using this for tests that will have a lot of data that I want to write in a spreadsheet of ten columns or more. One problem I have with the above example is that I have a constructor accepting one parameter for each column of data. I need to encapsulate that in a class. This is because I am thinking of using this to drive Selenium tests, where I need lots of data to enter into every field in the UI. The example below shows part of how I will handle this.

import static org.junit.Assert.assertEquals;

import java.util.Arrays;
import java.util.Collection;

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

@RunWith(Parameterized.class)
public final class MultiplicationParameterizedTestWithObject {

   private final DataUnderTest data;

   public MultiplicationParameterizedTestWithObject(final DataUnderTest theData) {
      data = theData;
   }

   @Parameters(name = "Multiplication test {index}: {0}")
   public static Collection<DataUnderTest[]> numbersToBeMultiplied() {
      return Arrays.asList(new DataUnderTest[][] {
            { new DataUnderTest("10 = 5 * 2", 10, 5, 2) },
            { new DataUnderTest("48 = 6 * 8", 48, 6, 8) },
            { new DataUnderTest("1,452 = 33 * 44", 1452, 33, 44) },
            { new DataUnderTest("1,044 = 87 * 12", 1044, 87, 12) },
            { new DataUnderTest("135 = 3 * 45", 135, 3, 45) },
            });
   }

   @Test
   public void sum() {
      final int firstNumber = data.getFirstNumber();
      final int secondNumber = data.getSecondNumber();
      final int actualResult = multiplyNumbers(firstNumber, secondNumber);
      final int expectedResult = data.getExpectedResult();
      assertEquals("Expected [" + firstNumber + " * " + secondNumber + " = "
            + expectedResult + "], not [" + actualResult + "]", expectedResult,
            actualResult);
   }

   public int multiplyNumbers(int a, int b) {
      int product = a * b;
      return product;
   }

   private static class DataUnderTest {
      private final String label;
      private final int expectedResult;
      private final int firstNumber;
      private final int secondNumber;

      public DataUnderTest(final String theLabel, final int theExpectedResult,
            final int theFirstNumber, final int theSecondNumber) {
         label = theLabel;
         expectedResult = theExpectedResult;
         firstNumber = theFirstNumber;
         secondNumber = theSecondNumber;
      }

      @Override
      public String toString() {
         return label;
      }

      public String getLabel() {
         return label;
      }

      public int getExpectedResult() {
         return expectedResult;
      }

      public int getFirstNumber() {
         return firstNumber;
      }

      public int getSecondNumber() {
         return secondNumber;
      }

   }
}

What I will need to do differently from above in my real test cases:

  • DataUnderTest will be much bigger - big enough that it will need to be in a separate java file.
  • The method annotated with @Parameters will read data from an Excel spreadsheet, perhaps using Java Excel API or The Apache POI Project.

What I like about this approach:

  • JUnit Parameterized seems to scale nicely because the method annotated with @Parameters can get data from anywhere.
  • By using DataUnderTest.toString(), I can still make good use of the same naming mechanism: @Parameters(name = "Multiplication test {index}: {0}"). By using this name declaration, the Eclipse results will look exactly the same as the first example because the {0} will be replaced by DataUnderTest.toString(). In my actual test, I plan to use the first column of data as the label.

What I don't like about this approach:

  • The fact that the method annotated with @Parameters has to return an Iterable of arrays, for example Collection<DataUnderTest[]>. It forces me to bind each element of the array to a constructor parameter, which is at least well defined, but doesn't seem so flexible, e.g. I cannot create an array that includes String and int without making it an Object array, in which case I would lose type information and would be forced to cast or somehow convert the values back to the types I want.

Thursday, October 16, 2014

Script to pump output into a text file and open it in an editor

I use this little script a lot when I am running some command in bash (on Cygwin in Windows) and I want to capture the output into a text file for display into my favourite editor (like UltreEdit).

For example, the tree command (or a recursive ls) will have a lot of output if you run it on a directory with a few children and a few levels of nested folders. Because the output is usually too large to view nicely in a single screen of text on a console, I will want to view it in a text editor where I can manipulate it: search through it, cut/copy/paste contents and generally modify it.

Before I wrote the script this post is about, I would do this in the following way:

tree > /tmp/temp.txt; u /tmp/temp.txt

Easy enough, but tiresome to type over and over.

In the above snippet, the u command refers to one of my most used custom scripts to open a text file in my favourite editor (with a few bells and whistles). It could be replaced with the following in this case:

tree > /tmp/temp.txt; Uedit32.exe `cygpath -w -a "/tmp/temp.txt"` &

Or more simply, a *nix tool like vim or less (though less won't let you edit it).

tree > /tmp/temp.txt; vim /tmp/temp.txt
tree > /tmp/temp.txt; less /tmp/temp.txt

Now, I will do this:

tree | intoTempFile

The intoTempFile script will write the output into a timestamped temp file (C:\cygwin\tmp\temp_20141016_220342.txt) and open it in UltraEdit for me. Here is the script.

#!/bin/bash

# ------------------------------------------------------------------------------
# -- Into Temp File.
# ------------------------------------------------------------------------------
# Redirect piped input into a temp file and open it in UltraEdit.
#     Usage: someCommand | intoTempFile.sh [altFilename.txt] [-t]

# ------------------------------------------------------------------------------
# -- Variables for this script.
# ------------------------------------------------------------------------------
# Shortcut for the name of this file - for docs.
commandName=`echo $0 | sed 's|.*/||'`

# Output file.
tempFile=/tmp/temp_$(date +"%Y%m%d_%H%M%S").txt

# To tee or not to tee?
shouldUseTee=no

# ------------------------------------------------------------------------------
# -- Common functions for this script.
# ------------------------------------------------------------------------------

# ===  FUNCTION  ===============================================================
#   DESCRIPTION:  Usage message.
#    PARAMETERS:  -
#       RETURNS:  -
# ==============================================================================
function usage() {
   echo "Usage: someCommand | $commandName [altFilename.txt] [-t]"
   echo "-t means use tee. Without it, nothing is output to console."
}

# ===  FUNCTION  ===============================================================
#   DESCRIPTION:  Process all arguments to script. How to handle getopts args
#                 and operands at the same time:
#                    http://stackoverflow.com/a/21169366/257233
#    PARAMETERS:  -
#       RETURNS:  -
# ==============================================================================
function processArguments() {
   # Arg checks.. No more than two args
   if [ $# -gt 2 ] ; then
      echo "** Incorrect number of args specified **"
      usage
      exit 22
   fi

   # Loop to handle all parameters
   non_option_parameters=()
   while true; do
      # Process single letter args.
      while getopts "$OPTIONS" option; do
         if ! processSingleLetterArguments "$option"; then exit 9; fi
      done
      if ((OPTIND > $#)); then break; fi
      non_option_parameters+=(${!OPTIND})
      # Handle operand arg - file name
      if [ -z "$searchTerm" ] ; then
         tempFile="${!OPTIND}"
      fi
     ((OPTIND++))
   done

   # ---------------------------------------------------------------------------
   # Post argument processing - logic that must be applied once we know all args.
   # ---------------------------------------------------------------------------

}

# ===  FUNCTION  ===============================================================
#   DESCRIPTION:  Process single letter args via getopts
#    PARAMETERS:  -
#       RETURNS:  -
# ==============================================================================
OPTIONS=":t"
function processSingleLetterArguments() {
   case "$1" in
      t ) shouldUseTee=yes;;
      \?)   usage "*** Invalid option to $commandName: -$OPTARG ***"; exit 10;;
      :)    usage "*** $commandName - option -$OPTARG requires an argument. ***"; exit 11;;
   esac
}

# ===  FUNCTION  ===============================================================
#   DESCRIPTION:  Output a single line
#                 Will query tee variable.
#    PARAMETERS:  1 - line to output
#       RETURNS:  -
# ==============================================================================
function outputLine() {
   if [ "$shouldUseTee" == "yes" ]  ; then
      echo "$1" 2>&1 | tee -a "${tempFile}"
   else
      echo "$1" >> "${tempFile}"
   fi
}


# ------------------------------------------------------------------------------
# -- Script logic.
# ------------------------------------------------------------------------------

# Process command line arguments.
processArguments "$@"

# Preserve indenting of source.
IFS='
'

touch  "${tempFile}"

outputLine "Starting output."
outputLine "----"
outputLine " "

while read -r x ; do
   outputLine "$x"
done

u.sh $tempFile

By default this will not show the output to the console. I can change that with the -t option as below - which will use tee to duplicate the output to console as well as a file. I don't usually use this though because it makes the script a lot slower.

tree | intoTempFile -t
Also, if I want to control the path to the text file being used, I can specify it like so.
tree | intoTempFile  /tmp/treeList.txt

Saturday, October 04, 2014

Add Eclipse Project to Local and Remote Git Repository

This is a brief tutorial on using Eclipse to check in projects to local and remote Git repositories.

  1. Install and configure EGit within Eclipse, if not already done.
  2. Create a project in Eclipse.
  3. Add project to local git repository.
  4. Create a project in GitHub (with the same name as our local project).
  5. Check in our project to the remote git repository.
  6. The two phases of commitment.
  7. Helpful Resources.

Prerequisites are as below.

  • You have an account already on GitHub. Free accounts can be used to create only public repositories i.e. everybody will be able to see your code. So if you need a private Git repository on GitHub, you have to pay.

To top of post.

Install and Configure EGit

Here you will install the EGit plugin within Eclipse. This gives Eclipse the ability to interact with Git repositories. If you have Eclipse Kepler (4.3), Eclipse Luna (4.4) or later, then this easily installed through the Eclipse Marketplace.

  1. Open Eclipse, go HelpEclipse Marketplace.
  2. In the search field, type EGit and press ENTER.
  3. The first result will be EGit - Git Team Provider 3.5.0 (latest version as of this writing).
  4. Click the Install button.
  5. Select Eclipse Git Team provider component.
  6. Select Next, accept license agreements, let it install, let Eclipse restart.

Before you can use EGit, you need to configure it.

Set up your identity. In Eclipse, go WindowPreferencesTeamGitConfiguration. Enter your name and email - Git will use this to identify who is making commits.

Set up location for local repositories. In Eclipse, go WindowPreferencesTeamGit and set a location for Default Repository Folder. I have used D:\Documents\Work\Git.

It is a good idea to create your Git repositories in a different directory than your Eclipse Workspace. The Git repository folders will hold lots of files related to Git setup, not just your project files. If you create your Git repository within your Eclipse Workspace, some operations in Eclipse would suffer a performance hit because they will have to scan all of these other files, not just project files.

You will need to create this directory first and it should be empty.

To top of post.

Create a project

In Eclipse, select FileNewProject → select whatever project type you want (I am using a Java Project). Give it a name and press Finish. The contents of the project aren't important - it is just a few bare files to show the next part of the process - adding it to a local repository and then a remote one.

Note that your project has been created in your Eclipse workspace. In my case, this was D:\Documents\Work\JavaTests\TestProject.

To top of post.

Add project to local git repository

In Package Explorer view, right click on the project you just created and select TeamShare Project. In the Share Project dialog, select Git and then click Next.

The next screen is Configure Git Repository.

I am not selecting Use or create repository in parent folder of project for reasons stated above - the repository folder will contain a lot of Git-specific files apart from my project files and I do not want Eclipse having to scan these folders.

The general idea is that you have one project per repository, so we make one repo for this project. Click Create.

Give the new repository the same name as your project and click Finish.

I am now back on the Configure Git Repository dialog.

I can see the following:

  • Repository: D:\Documents\Work\Git\TestProject\.git - all the files related to Git go here.
  • Working Directory: D:\Documents\Work\Git\TestProject - the parent folder for the Git directory and the (new, target) project directory.
  • Current Location: D:\Documents\Work\JavaTests\TestProject - where the project directory current is, but it will be moved to Target.
  • Target Location: D:\Documents\Work\Git\TestProject\TestProject - new location for the project files.

Note that the Working directory field (read only) gives the repository location (D:\Documents\Work\Git in my case). Also note that the Current Location and Target Location are different. Current Location shows where my files are right now - in my Eclipse workspace. Target Location shows where my files will be moved to - a folder underneath the Git repository Working directory.

This means that when you press Finish, Eclipse will move your files out of the Eclipse workspace and into the Git repository folder. Don't be surprised - this is normal. It takes some getting used to if you haven't used Git before. In the Git repository, you will also notice a new folder - .git, which contains all the files Git uses to manage the repository.

Click Finish.

Now take some time to notice what has changed. The icons in Package Explorer are different.

Note the duplication in names - I have a Git repository called TestProject containing a project called TestProject. The icons reflect Git state. See EGit/User Guide/State which has this image showing at a glance the different states.

Also note that your files have indeed been moved out of your Eclipse workspace and into your Git repository.

Open up the Git Staging view: WindowShow ViewOther → select GitGit Staging.

This view makes it very easy to commit changes.

Click and drag the files down to the Staged Changes box. Type a commit message in the Commit Message text area.

Click Commit.

You can also do this with the commit action. Control+shift+3 is the default keyboard shortcut, or right click on the project and select Teamcommit. However, I find the Git Staging view much easier to use.

To top of post.

Create a project in GitHub (with the same name as our local project)

Go to GitHub and log in.

On the actions menu, select New repository.

Give Repository name the same value as your Eclipse project's name, and whatever Description is appropriate. Note that my repository is Public, so that anyone will be able to see what I check into it. Click Create Repository.

This screen gives us very important information that we will use in the next step - the HTTP URL for interacting with this repository from EGit in Eclipse: https://github.com/robertmarkbram/TestProject.git.

To top of post.

Check in our project to the remote git repository

Back in Eclipse, right click on your project in Package Explorer and select TeamRemotePush...

Most importantly, in the URI field, enter the URL we got from GitHub earlier. The Host and Repository path fields will auto-fill correctly. In the Authentication section, enter your GitHub username and password. I let Eclipse store these details by selecting Store in Secure Store. If this is the first time I have done it, Eclipse will ask me to set up a Master Password.

Click Next and you will see the Push to: ... dialog.

Click Add All Branches Spec. Under Source ref select master [branch]. Under Destination ref, select refs/heads/master.

Click Next and see the Push Confirmation dialog. Click Finish.

The project files will then be pushed to the GitHub remote repository. When it is complete, you will see a results dialog.

If you refresh your GitHub repository, you should now see the files committed remotely.

And underneath the main project folder are my files.

To top of post.

The two phases of commitment

We know have a system of two phase commits, so to speak. Work locally and commit changes to the local repository so you have a history and backups as needed.

When you commit, you have a choice of using Commit or Commit and Push. Just choosing Commit will commit your changes to the local repository. Selecting Commit and Push will commit them to your local repository and then push them to the remote repository - e.g. GitHub. The first time you use Commit and Push, it will ask you to set up the remote repository.

Press next and you will see the Push Branch master dialog wherein you tell Git what to do when pulling changes from the upstream repository i.e. bring changes from GitHub back into your local.

Hit Next and the rest of this is like any other commit, but you will have sent your changes to two repositories - local and GitHub.

To top of post.

Helpful Resources

To top of post.