2007-07-12
| Revision History | ||
|---|---|---|
| Revision 2.0.3 | 2007-07-12 | Kate Ward <kate.ward@forestent.com> |
| Revision 2.0.2 | 2007-04-22 | Kate Ward <kate.ward@forestent.com> |
| Revision 2.0.1 | 2007-02-21 | Kate Ward <kate.ward@forestent.com> |
| Revision 2.0.0 | 2007-02-20 | Kate Ward <kate.ward@forestent.com> |
Table of Contents
Table of Contents
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.
Tested Operating Systems
Tested Shells
Bourne Shell (sh)
BASH - GNU Bourne Again SHell (bash)
DASH (dash)
Korn Shell (ksh)
pdksh - Public Domain Korn Shell (pdksh)
See the appropriate Release Notes (doc/RELEASE_NOTES-X.X.X.txt) for this release for the actual versions tested.
A list of contributors to shUnit2 can be found in the source archive as doc/contributors.txt. I want to personally thank all those who have contributed to make this a better tool.
Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address: <kate.ward@forestent.com>.
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 shunit2 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 shunit2 script. The basic functionality for the script above goes like this.
When shUnit2 is sourced, it first looks to see if a suite() function has been declared. If it exists, it is called as it is expected to contain a list of tests to be executed. If it doesn't exist (and it doesn't in the above example), shUnit2 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, shunit2 will go to work.
Before any tests are executed, shUnit2 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.
shUnit2 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, shUnit2 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, shUnit2 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}." \
- '1999' "${year}"
-}
-
-# 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 shUnit2.
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.
Table of Contents
Table 3.1. asserts
| - void - |
-
Asserts that expected and - actual are equal to one another. The message is - optional. - | |||||||||||||||
| - void - |
-
Asserts that value is | |||||||||||||||
| - void - |
-
Asserts that value is not | |||||||||||||||
| - void - |
-
This function is functionally equivalent to
- | |||||||||||||||
| - void - |
-
Asserts that unexpected and - actual are not - equal to one another. The message is optional. - | |||||||||||||||
| - void - |
-
Asserts that a given shell test condition is true. The message is - optional. -Testing whether something is true or false is easy enough by using - the assertEquals/assertNotSame functions. Shell supports much more - complicated tests though, and a means to support them was needed. As such, - this function tests that conditions are true or false through evaluation - rather than just looking for a true or false. -
- The following test will succeed:
- assertTrue "[ 34 -gt 23 ]"- The following test will fail with a message: assertTrue "test failed" "[ -r '/non/existent/file' ]" | |||||||||||||||
| - void - |
-
Asserts that a given shell test condition is false. The message is - optional. -Testing whether something is true or false is easy enough by using - the assertEquals/assertNotSame functions. Shell supports much more - complicated tests though, and a means to support them was needed. As such, - this function tests that conditions are true or false through evaluation - rather than just looking for a true or false. -
- The following test will succeed:
- assertFalse "[ 'apples' = 'oranges' ]"- The following test will fail with a message: assertFalse "test failed" "[ 1 -eq 1 -a 2 -eq 2 ]" |
Table 3.2. failures
| - void - |
-
Fails the test immediately, with the optional message. - | |||||||||||||||
| - void - |
-
Fails the test if unexpected and - actual are not - equal to one another. The message is optional. - | |||||||||||||||
| - void - |
-
Indicate test failure because arguments were not the same. The - message is optional. - | |||||||||||||||
| - void - |
-
Fails the test if expected and - actual are equal to one another. The message is - optional. - |
Table 3.3. suites
| - void - |
-
This function can be optionally overridden by the user in their test - suite. -If this function exists, it will be called when
- shunit2 is sourced. If it does not exist, shUnit2 will
- search the parent script for all functions beginning with the word
- | |||||
| - void - |
-
This function adds a function name to the list of tests scheduled for
- execution as part of this test suite. This function should only be called
- from within the | |||||
| - void - |
-
This function can be be optionally overridden by the user in their - test suite. -If this function exists, it will be called once before any tests are - run. It is useful to prepare a common environment for all tests. - | |||||
| - void - |
-
This function can be be optionally overridden by the user in their - test suite. -If this function exists, it will be called once after all tests are - completed. It is useful to clean up the environment after all tests. - | |||||
| - void - |
-
This function can be be optionally overridden by the user in their - test suite. -If this function exists, it will be called before each test is run. - It is useful to reset the environment before each test. - | |||||
| - void - |
-
This function can be be optionally overridden by the user in their - test suite. -If this function exists, it will be called after each test completes. - It is useful to clean up the environment after each test. - |