diff options
Diffstat (limited to 'contrib/shunit2-2.0.3/src/docbook')
| -rw-r--r-- | contrib/shunit2-2.0.3/src/docbook/functions.xml | 14 | ||||
| -rw-r--r-- | contrib/shunit2-2.0.3/src/docbook/introduction.xml | 50 | ||||
| -rw-r--r-- | contrib/shunit2-2.0.3/src/docbook/quickstart.xml | 86 | ||||
| -rw-r--r-- | contrib/shunit2-2.0.3/src/docbook/shunit2.xml | 85 |
4 files changed, 235 insertions, 0 deletions
diff --git a/contrib/shunit2-2.0.3/src/docbook/functions.xml b/contrib/shunit2-2.0.3/src/docbook/functions.xml new file mode 100644 index 0000000..c960e55 --- /dev/null +++ b/contrib/shunit2-2.0.3/src/docbook/functions.xml @@ -0,0 +1,14 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- +$Id$ +vim:softtabstop=2 shiftwidth=2 +--> + +<!-- ========================================================================= +Functions +--> + +<chapter id="functions"> + <title>Functions</title> + <para>This XML file is a placeholder. It is meant to be overwritten with the dynamically generated XML document that is extracted from the source code.</para> +</chapter> diff --git a/contrib/shunit2-2.0.3/src/docbook/introduction.xml b/contrib/shunit2-2.0.3/src/docbook/introduction.xml new file mode 100644 index 0000000..d71b091 --- /dev/null +++ b/contrib/shunit2-2.0.3/src/docbook/introduction.xml @@ -0,0 +1,50 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- +$Id$ +vim:softtabstop=2 shiftwidth=2 + --> + +<!-- ========================================================================= +Introduction +--> + +<chapter label="1" id="introduction"> + + <title>Introduction</title> + <para>shUnit2 is a unit test framework for Bourne based shell scripts, and it is designed to work in a similar manner to <ulink url="http://www.junit.org/">JUnit</ulink>, <ulink url="http://pyunit.sourceforge.net/">PyUnit</ulink>, etc.</para> + + <para>shUnit2 was originally developed to provide a consistent testing solution for <ulink url="http://log4sh.sourceforge.net/">log4sh</ulink>, 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 (<filename>/bin/bash</filename> on Linux to be specific), and then not working under another shell (<filename>/bin/sh</filename> 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.</para> + + <para><blockquote><title>Tested Operating Systems</title> + <itemizedlist> + <listitem><para><ulink url="http://www.cygwin.com/">Cygwin</ulink></para></listitem> + <listitem><para><ulink url="http://www.freebsd.org/">FreeBSD</ulink> (user supported)</para></listitem> + <listitem><para>Linux (<ulink url="http://www.gentoo.org/">Gentoo</ulink>, <ulink url="http://www.ubuntu.com/">Ubuntu</ulink>)</para></listitem> + <listitem><para><ulink url="http://www.apple.com/macosx/">Mac OS X</ulink></para></listitem> + <listitem><para><ulink url="http://www.sun.com/software/solaris/">Solaris</ulink> 8, 9, 10</para></listitem> + </itemizedlist> + </blockquote></para> + + <para><blockquote><title>Tested Shells</title> + <itemizedlist> + <listitem><para>Bourne Shell (<command>sh</command>)</para></listitem> + <listitem><para><ulink url="http://www.gnu.org/software/bash/">BASH</ulink> - GNU Bourne Again SHell (<command>bash</command>)</para></listitem> + <listitem><para><ulink url="http://gondor.apana.org.au/~herbert/dash/">DASH</ulink> (<command>dash</command>)</para></listitem> + <listitem><para><ulink url="http://www.kornshell.com/">Korn Shell</ulink> (<command>ksh</command>)</para></listitem> + <listitem><para><ulink url="http://web.cs.mun.ca/~michael/pdksh/">pdksh</ulink> - Public Domain Korn Shell (<command>pdksh</command>)</para></listitem> + </itemizedlist> + </blockquote></para> + + <para>See the appropriate Release Notes (<filename>doc/RELEASE_NOTES-X.X.X.txt</filename>) for this release for the actual versions tested.</para> + + <!-- Give credit where credit is due...very important --> + <section id="credits"><title>Credits / Contributors</title> + <para>A list of contributors to shUnit2 can be found in the source archive as <filename>doc/contributors.txt</filename>. I want to personally thank all those who have contributed to make this a better tool.</para> + </section> + + <!-- Feedback --> + <section id="feedback"><title>Feedback</title> + <para>Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address: <email>&myEmail;</email>.</para> + </section> + +</chapter> diff --git a/contrib/shunit2-2.0.3/src/docbook/quickstart.xml b/contrib/shunit2-2.0.3/src/docbook/quickstart.xml new file mode 100644 index 0000000..d009cb6 --- /dev/null +++ b/contrib/shunit2-2.0.3/src/docbook/quickstart.xml @@ -0,0 +1,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> diff --git a/contrib/shunit2-2.0.3/src/docbook/shunit2.xml b/contrib/shunit2-2.0.3/src/docbook/shunit2.xml new file mode 100644 index 0000000..25b3fed --- /dev/null +++ b/contrib/shunit2-2.0.3/src/docbook/shunit2.xml @@ -0,0 +1,85 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- +$Id$ +vim: softtabstop=2 shiftwidth=2 +--> +<!-- + +This document can be converted to HTML using the following commands: + +$ java -cp xalan-2.6.0.jar \ + org.apache.xalan.xslt.Process -xml -in log4sh.xml -xsl tldp-one-page.xsl + +$ xsltproc tldp-one-page.xsl log4sh.xml |xmllint -noblanks - + +--> + +<!DOCTYPE book + PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ + + <!ENTITY functions SYSTEM "functions.xml"> + <!ENTITY introduction SYSTEM "introduction.xml"> + <!ENTITY quickstart SYSTEM "quickstart.xml"> + + <!ENTITY myEmail "kate.ward@forestent.com"> + <!ENTITY isoDate "@@ISO_DATE@@"> + + <!ENTITY shunit2 "<command>shunit2</command>"> +]> + +<book id="shUnit2" lang="en-US"><title>shUnit2</title> + <bookinfo> + <title>shUnit2 version 2.0.3</title> + <authorgroup> + <author> + <firstname>Kate</firstname><surname>Ward</surname> + <affiliation> + <address> + <email>&myEmail;</email> + </address> + </affiliation> + </author> + </authorgroup> + + <!-- All dates specified in ISO "YYYY-MM-DD" format --> + <pubdate>&isoDate;</pubdate> + + <!-- TODO flush out like bookinfo in docbook-tdg --> + + <!-- Most recent revision goes at the top; list in descending order --> + <revhistory> + <revision> + <revnumber>2.0.3</revnumber> + <date>2007-07-12</date> + <authorinitials>Kate Ward <&myEmail;></authorinitials> + </revision> + + <revision> + <revnumber>2.0.2</revnumber> + <date>2007-04-22</date> + <authorinitials>Kate Ward <&myEmail;></authorinitials> + </revision> + + <revision> + <revnumber>2.0.1</revnumber> + <date>2007-02-21</date> + <authorinitials>Kate Ward <&myEmail;></authorinitials> + </revision> + + <revision> + <revnumber>2.0.0</revnumber> + <date>2007-02-20</date> + <authorinitials>Kate Ward <&myEmail;></authorinitials> + </revision> + </revhistory> + + <!-- Provide a good abstract; a couple of sentences is sufficient --> + <abstract> + <para><ulink url="http://sourceforge.net/projects/shunit2">shUnit2</ulink> is a unit test framework for Bourne based shell scripts, and it is designed to work in a similar manner to <ulink url="http://www.junit.org/">JUnit</ulink>, <ulink url="http://pyunit.sourceforge.net/">PyUnit</ulink>, etc.</para> + </abstract> + </bookinfo> + + &introduction; + &quickstart; + &functions; +</book> |