1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
<?xml version="1.0" encoding="UTF-8"?>
<!--
$Id: quickstart.xml 230 2006-08-19 22:32:02Z sfsetse $
vim:softtabstop=2 shiftwidth=2
-->
<!-- =========================================================================
Quickstart
-->
<chapter id="quickstart">
<title>Quickstart</title>
<para>This chapter will give a very quick start to running unit tests with shUnit2. More information is located in other chapters.</para>
<para>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.</para>
<programlisting>
<![CDATA[
#! /bin/sh
testEquality()
{
assertEquals 1 1
}
# load shunit2
. ./shunit2
]]>
</programlisting>
<para>Running the unit test should give results similar to the following.</para>
<screen>
<![CDATA[
#
# Performing tests
#
testEquality
#
# Test report
#
tests passed: 1
tests failed: 0
tests total: 1
success rate: 100%
]]>
</screen>
<para>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.</para>
<para>When shUnit2 is sourced, it first looks to see if a <function>suite()</function> 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 <literal>test</literal>, 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.</para>
<para>Before any tests are executed, shUnit2 again looks for a function, this time one named <function>oneTimeSetUp()</function>. 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 <function>oneTimeTearDown()</function> function that does the same thing, but once all the tests have been completed. It is good for removing temporary directories, etc.</para>
<para>shUnit2 is now ready to run tests. Before doing so though, it again looks for another function that might be declared, one named <function>setUp()</function>. 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 <function>tearDown()</function>. 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.</para>
<para>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.</para>
<para>We should now try adding a test that fails. Change your unit test to look like this.</para>
<programlisting>
<![CDATA[
#! /bin/sh
testEquality()
{
assertEquals 1 1
}
testPartyLikeItIs1999()
{
year=`date '+%Y'`
assertEquals "It's not 1999 :-( This is ${year}." \
'1999' "${year}"
}
# load shunit2
. ./shunit2
]]>
</programlisting>
<para>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.</para>
<para>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 <ulink url="http://log4sh.sourceforge.net/">log4sh</ulink>. 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.</para>
</chapter>
|
