The TestKit is a collection of scripts that leverages the ShUnit unit testing environment. The TestKit provides a pattern for creating test suites using a simple configuration file approach. Full reporting on test runs is provided in a convenient tabular format.
Generally, writing a test script using the TestKit is a matter of minutes. A blank test is provided as a template, and that can be expanded with whatever test steps are needed. (See examples/blank_test.sh)
TestKit (and ShUnit) are implemented in the GNU Bash script language, but a TestKit test script can invoke external applications, written in whatever programming language or scripting tool is desired, using the standard POSIX interfaces.
The testkit is provided under the Apache License, version 2.0 (the "License"). The license is available at: http://www.apache.org/licenses/LICENSE-2.0
Follow these steps to download and install a new "vanilla" version of the
TestKit:
sudo
mkdir /opt/feistymeow.org
sudo chown -R $USER /opt/feistymeow.org
cd /opt/feistymeow.org
git clone git://feistymeow.org/feisty_meow
ls feisty_meow/testkit # the testkit location; can be copied
elsewhere for use.
The above steps may have been used to kick-start the local version of the TestKit. It is perfectly valid to download the testkit and then copy it into one's own source code for use; this is enabled under the Apache License.
It is also possible to check out the TestKit within one's own code base (by adding the Feisty Meow® Codebase that was retrieved above). Then one can retrieve an updated Feisty Meow® TestKit by running "git pull" on the "feisty_meow" folder. This will get the latest version of TestKit without disturbing whatever project's revision control repository contains the TestKit for testing.
Linux is the easiest environment for running the TestKit, given that the tests were built using the bash shell within a Linux environment. If some of the packages used in the tests are missing (such as expect and gnu awk), these may need to be installed from the appropriate repository for your Linux distribution. Most distributions include these packages automatically however.
The test suite runs well on modern Macs with Intel CPUs. Due to
some differences in the versions of a few applications on the Mac, some
GNU tools may need to be installed to run the TestKit. These are
available via the Brew installer tool.
The Cygwin Unix emulation system is required to run the TestKit on Windows. This package is available at: http://cygwin.com/install.html
The default packages selected by Cygwin are the starting point of the install. In addition to those packages, the following packages are also required (see list below). Rather than using the cygwin setup program for this task, the next section describes how to install Cygwin with the apt-cyg tool. Apt-cyg is the preferred method, since it involves less interaction with the somewhat clunky Cygwin installer. If necessary, it is possible to install all the packages without apt-cyg just by using the Cygwin setup program. To find each of these packages more easily, try switching the “View” button on the Cygwin setup program to “Full” to get an alphabetized list.
bc
crypt
cygutils
emacs
email
expect
gcc-g++
git
gitk
gvim
inetutils
less
make
mutt
ncftp
openssh
perl
procps
python
sharutils
shutdown
subversion
time
unzip
util-linux
vim
wget
xinit
xterm
zip
The apt-cyg program brings the convenience of the Debian and Ubuntu installer application (apt-get) to Cygwin. This program does require a couple of additional setup steps. This material is drawn from the apt-cyg home page: https://github.com/transcode-open/apt-cyg
1. Install the basic Cygwin packages with setup.exe (rather than the long list above), but add these two packages which are not selected by default:
2. Download and install the apt-cyg program from within a Cygwin bash prompt:
lynx
-source rawgit.com/transcode-open/apt-cyg/master/apt-cyg > apt-cyg
install apt-cyg /bin
3. Install the packages required for the TestKit:
apt-cyg
install bc crypt cygutils emacs email expect gcc-g++ git gitk gvim \
inetutils less make mutt ncftp openssh perl procps python
sharutils \
shutdown time unzip util-linux vim xinit xterm zip
4. The installation will run for a while but then should conclude with all required packages installed.
Running tests in TestKit uses a configuration file called “testkit.config” to define the environment and, optionally, which test scripts to run. This file is the main switchboard that defines where the tests will find the resources they require.
The configuration file can be specified via the environment variable “TESTKIT_CFG_FILE”. This variable can be set to any location, enabling the configuration file to reside in a directory other than the toolkit folder. If the variable is not defined, then the testing config file defaults to “$TESTKIT_ROOT/testkit.config”.
The TESTKIT_ROOT variable is frequently referred to in command examples. It is set up automatically by the prepare_tools script (see below).Once the TestKit configuration file has been established, running a whole
test suite can be accomplished with this command:
bash {TESTKIT_FOLDER}/test_driver.sh
Where the {TESTKIT_FOLDER} should be replaced with whatever path the TestKit is stored in.
Alternatively, if the TESTKIT_ROOT folder is already established, the tests can be run with:
bash "$TESTKIT_ROOT/test_driver.sh"
The test_driver.sh script will output a few informative lines of text before printing a table of the tests that it intends to run.
After the test plan is shown, all of the tests listed will be executed in the order they are listed in, and they will each produce output. Each individual test (usually a separate bash script) produces a summary at the end of its run with a count of tests and a report of the tests success or failure.
At the end of all the tests in the suite, the table of tests is printed again with the results for each test. For example, this is a test run that had no errors in any test (that's good, since it is our super simple example test):
The above shows the "summary" view, which does not allow the individual tests to output to the console. If the "summary" flag is not passed, then the output from all the test runs is also shown.
Even when the summary view is used, all output files can be examined after the run. For example, in the above, the mentioned output file "test_log.vKf7J3" can be checked to see exactly what happened during the test.
A test with a failure in it will have “FAIL” next to the test that failed, and the final output line will start with “FAILURE”. For example:
01:
OKAY – AckPfft_Tests/Gorp_Tests/deslagToaster.sh
02: FAIL – AckPfft_Tests/Gorp_Tests/spumeMerchantry.sh
03: OKAY – AckPfft_Tests/Gorp_Tests/octopusLauncher.sh
…
22: OKAY -- Snargle_Tests/scramTests/scramForPetunias.sh
FAILURE: 1 Tests Failed out of 22 Tests.
A failed test will also return a non-zero value from the test execution, enabling the run of a test suite to be tested for success when launched externally, such as from a continuous integration system.
If one wishes to run individual tests within the test suite, rather than the entire suite, this is done by loading the TestKit variables into the current shell environment, like so:
cd
{TESTKIT_FOLDER} # replace with actual location of
TestKit.
source prepare_tools.sh prepare_tools.sh
source $TESTKIT_ROOT/library/process_configuration.sh
define_and_export_variables
After loading the TestKit environment, one can execute a specific test and see its results, for example:
cd
examples
bash blank_test.sh
The test will run and output its results to the console (that is, output is sent to standard out and standard error, to be more precise).
The ShUnit test environment provides several functions that can be used to evaluate whether a test was successful or whether a result was the expected value.
The blank test (in examples/blank_test.sh) shows off every method that exists in our version of ShUnit and describes how the functions can be used for testing. Please refer to that for a good set of examples. This test is also semi-canonical, in that it implements every phase of testing, including setup and tear down methods.
For more details on ShUnit in general or to get a later version, this is the official website: https://github.com/kward/shunit2
Note however that we have made some customizations in reporting in the version stored with the testkit, so some features may be missed if a newer version is placed in the testkit's "shunit" folder.