shUnit version 2.0.0

shUnit2 is a unit test framework for Bourne based shell scripts, and it is designed to work in a similar manner to JUnit, PyUnit, etc.

shUnit2 was originally developed to provide a consistent testing solution for log4sh, a shell based logging framework similar to log4j. During the development of that product, the problem of having things work just fine under one shell (/bin/bash on Linux to be specific), and then not working under another shell (/bin/sh on Solaris), kept coming up. Although there were several simple tests ran, they were not adaquate and did not catch very many corner cases. The decision was finally made to write a proper unit test framework after after multiple brown-bag releases were made.

See the appropriate Release Notes (doc/RELEASE_NOTES-X.X.X.txt) for this release for the actual versions tested.

This chapter will give a very quick start to running unit tests with shUnit2. More information is located in other chapters.

Here is a quick sample script to show how easy it is to write a unit test in shell. It expects that you have a copy of shunit in the same directory as the script.

#! /bin/sh

testEquality()
{
  assertEquals 1 1
}

# load shunit2
. ./shunit2

  

Running the unit test should give results similar to the following.

#
# Performing tests
#
testEquality

#
# Test report
#
tests passed: 1
tests failed: 0
tests total:  1
success rate: 100%

  

Wohoo! You've just run your first successful unit test. So, what just happened? Quite a bit really, and it all happened simply by sourcing the shunit script. The basic functionality for the script above goes like this.

When shunit is sourced, it first looks to see if a suite() function has been declared. If it exists, it is executed as shunit expects it to contain a list of tests to be executed. If it doesn't exist (and it doesn't in the above example), shunit will look on its own for any functions that start with the string test, and adds those to an internal list of tests to execute. Once a list of test functions to be run has been determined, shunit will go to work.

Before any tests are executed, shunit again looks for a function, this time one named oneTimeSetUp(). If it exists, it will be run. This function is normally used to setup the environment for all tests to be run. Things like creating directories for output or setting environment variables are good to place here. Just so you know, you can also declare a corresponding function named oneTimeTearDown() function that does the same thing, but once all the tests have been completed. It is good for removing temporary directories, etc.

shunit is now ready to run tests. Before doing so though, it again looks for another function that might be declared, one named setUp(). If the function exists, it will be run before each test. It is good for resetting the environment so that each test starts with a clean slate. At this stage, the first test is finally run. The success of the test is recorded for a report that will be generated later. After the test is run, shunit looks for a final function that might be declared, one named tearDown(). If it exists, it will be run after each test. It is a good place for cleaning up after each test, maybe doing things like removing files that were created, or removing directories. This set of steps, setUp() > test() > tearDown(), is repeated for all of the available tests.

Once all the work is done, shunit will generate the nice report you saw above. A summary of all the successes and failures will be given so that you know how well your code is doing.

We should now try adding a test that fails. Change your unit test to look like this.

#! /bin/sh

testEquality()
{
  assertEquals 1 1
}

testPartyLikeItIs1999()
{
  year=`date '+%Y'`
  assertEquals "It's not 1999 :-( This is ${year}." \
      "${year}" '1999'
}

# load shunit2
. ./shunit2

  

So, what did you get? I guess it told you that this isn't 1999. Bummer, eh? Hopefully, you noticed a couple of things that were different about the second test. First, we added an optional message that the user will see if the assert fails. Second, we did comparisons of strings instead of integers as in the first test. It doesn't matter whether you are testing for equality of strings or integers. Both work equally well with shunit.

Hopefully, this is enough to get you started with unit testing. If you want a ton more examples, take a look at the tests provided with log4sh. Examples of much more advanced usage can be seen there. shUnit2 was after all written to help with the unit testing problems that log4sh had.