abra zsh config 2.0
This commit is contained in:
Andrey Anurin
221
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/CHANGES-2.1.txt
vendored
Normal file
221
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/CHANGES-2.1.txt
vendored
Normal file
@@ -0,0 +1,221 @@
|
||||
Changes in shUnit2 2.1.X
|
||||
========================
|
||||
|
||||
Changes with 2.1.7
|
||||
------------------
|
||||
|
||||
Updated the LGPL license from http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt.
|
||||
|
||||
|
||||
Changes with 2.1.6
|
||||
------------------
|
||||
|
||||
Removed all references to the DocBook documentation.
|
||||
|
||||
Simplified the 'src' structure.
|
||||
|
||||
Fixed error message in fail() that stated wrong number of required arguments.
|
||||
|
||||
Updated lib/versions.
|
||||
|
||||
Fixed bug in _shunit_mktempDir() where a failure occurred when the 'od' command
|
||||
was not present in /usr/bin.
|
||||
|
||||
Renamed shunit_tmpDir variable to SHUNIT_TMPDIR to closer match the standard
|
||||
TMPDIR variable.
|
||||
|
||||
Added support for calling shunit2 as an executable, in addition to the existing
|
||||
method of sourcing it in as a library. This allows users to keep tests working
|
||||
despite the location of the shunit2 executable being different for each OS
|
||||
distribution.
|
||||
|
||||
Issue #14: Improved handling of some strange chars (e.g. single and double
|
||||
quotes) in messages.
|
||||
|
||||
Issue# 27: Fixed error message for assertSame().
|
||||
|
||||
Issue# 25: Added check and error message to user when phantom functions are
|
||||
written to a partition mounted with noexec.
|
||||
|
||||
Issue# 11: Added support for defining functions like 'function someFunction()'.
|
||||
|
||||
|
||||
Changes with 2.1.5
|
||||
------------------
|
||||
|
||||
Issue# 1: Fixed bug pointed out by R Bernstein in the trap code where certain
|
||||
types of exit conditions did not generate the ending report.
|
||||
|
||||
Issue# 2: Added assertNotEquals() assert.
|
||||
|
||||
Issue# 3: Moved check for unset variables out of shUnit2 into the unit tests.
|
||||
Testing poorly written software blows up if this check is in, but it is only
|
||||
interesting for shUnit2 itself. Added shunit_test_output.sh unit test for this.
|
||||
Some shells still do not catch such errors properly (e.g. Bourne shell and BASH
|
||||
2.x).
|
||||
|
||||
Added new custom assert in test_helpers to check for output to STDOUT, and none
|
||||
to STDERR.
|
||||
|
||||
Replaced fatal message in the temp directory creation with a _shunit_fatal()
|
||||
function call.
|
||||
|
||||
Fixed test_output unit test so it works now that the 'set -u' stuff was removed
|
||||
for Issue# 3.
|
||||
|
||||
Flushed out the coding standards in the README.txt a bit more, and brought the
|
||||
shunit2 code up to par with the documented standards.
|
||||
|
||||
Issue# 4: Completely changed the reporting output to be a closer match for
|
||||
JUnit and PyUnit. As a result, tests are counted separately from assertions.
|
||||
|
||||
Provide public shunit_tmpDir variable that can be used by unit test scripts that
|
||||
need automated and guaranteed cleanup.
|
||||
|
||||
Issue# 7: Fixed duplicated printing of messages passed to asserts.
|
||||
|
||||
Per code review, fixed wording of failSame() and failNotSame() messages.
|
||||
|
||||
Replaced version_info.sh with versions library and made appropriate changes in
|
||||
other scripts to use it.
|
||||
|
||||
Added gen_test_results.sh to make releases easier.
|
||||
|
||||
Fixed bugs in shlib_relToAbsPath() in shlib.
|
||||
|
||||
Converted DocBook documentation to reStructuredText for easier maintenance. The
|
||||
DocBook documentation is now considered obsolete, and will be removed in a
|
||||
future release.
|
||||
|
||||
Issue# 5: Fixed the documentation around the usage of failures.
|
||||
|
||||
Issue# 9: Added unit tests and updated documentation to demonstrate the
|
||||
requirement of quoting values twice when macros are used. This is due to how
|
||||
shell parses arguments.
|
||||
|
||||
When an invalid number of arguments is passed to a function, the invalid number
|
||||
is returned to the user so they are more aware of what the cause might be.
|
||||
|
||||
|
||||
Changes with 2.1.4
|
||||
------------------
|
||||
|
||||
Removed the _shunit_functionExists() function as it was dead code.
|
||||
|
||||
Fixed zsh version number check in version_info.
|
||||
|
||||
Fixed bug in last resort temporary directory creation.
|
||||
|
||||
Fixed off-by-one in exit value for scripts caught by the trap handler.
|
||||
|
||||
Added argument count error checking to all functions.
|
||||
|
||||
Added mkdir_test.sh example.
|
||||
|
||||
Moved src/test into src/shell to better match structure used with shFlags.
|
||||
|
||||
Fixed problem where null values were not handled properly under ksh.
|
||||
|
||||
Added support for outputting line numbers as part of assert messages.
|
||||
|
||||
Started documenting the coding standards, and changed some variable names as a
|
||||
result.
|
||||
|
||||
Improved zsh version and option checks.
|
||||
|
||||
Renamed the __SHUNIT_VERSION variable to SHUNIT_VERSION.
|
||||
|
||||
|
||||
Changes with 2.1.3
|
||||
------------------
|
||||
|
||||
Added some explicit variable defaults, even though the variables are set, as
|
||||
they sometimes behave strange when the script is canceled.
|
||||
|
||||
Additional workarounds for zsh compatibility.
|
||||
|
||||
shUnit2 now exits with a non-zero exit code if any of the tests failed. This was
|
||||
done for automated testing frameworks. Tests that were skipped are not
|
||||
considered failures, and do not affect the exit code.
|
||||
|
||||
Changed detection of STDERR output in unit tests.
|
||||
|
||||
|
||||
Changes with 2.1.2
|
||||
------------------
|
||||
|
||||
Unset additional variables that were missed.
|
||||
|
||||
Added checks and workarounds to improve zsh compatibility.
|
||||
|
||||
Added some argument count checks ``assertEquals()``, ``assertNull()``, and
|
||||
``assertSame()``
|
||||
|
||||
|
||||
Changes with 2.1.1
|
||||
------------------
|
||||
|
||||
Fixed bug where ``fail()`` was not honoring skipping.
|
||||
|
||||
Fixed problem with ``docs-docbook-prep`` target that prevented it from working.
|
||||
(Thanks to Bryan Larsen for pointing this out.)
|
||||
|
||||
Changed the test in ``assertFalse()`` so that any non-zero value registers as
|
||||
false. (Credits to Bryan Larsen)
|
||||
|
||||
Major fiddling to bring more in line with `JUnit <http://junit.org/>`. Asserts
|
||||
give better output when no message is given, and failures now just fail.
|
||||
|
||||
It was pointed out that the simple 'failed' message for a failed assert was not
|
||||
only insufficient, it was nonstandard (when compared to JUnit) and didn't
|
||||
provide the user with an expected vs actual result. The code was revised
|
||||
somewhat to bring closer into alignment with JUnit (v4.3.1 specifically) so
|
||||
that it feels more "normal". (Credits to Richard Jensen)
|
||||
|
||||
As part of the JUnit realignment, it was noticed that fail*() functions in
|
||||
JUnit don't actually do any comparisons themselves. They only generate a
|
||||
failure message. Updated the code to match.
|
||||
|
||||
Added self-testing unit tests. Kinda horkey, but they did find bugs during the
|
||||
JUnit realignment.
|
||||
|
||||
Fixed the code for returning from asserts as the return was being called before
|
||||
the unsetting of variables occurred. (Credits to Mathias Goldau)
|
||||
|
||||
The assert(True|False)() functions now accept an integer value for a
|
||||
conditional test. A value of '0' is considered 'true', while any non-zero value
|
||||
is considered 'false'.
|
||||
|
||||
All public functions now fill use default values to work properly with the '-x'
|
||||
shell debugging flag.
|
||||
|
||||
Fixed the method of percent calculation for the report to get achieve better
|
||||
accuracy.
|
||||
|
||||
|
||||
Changes with 2.1.0 (since 2.0.1)
|
||||
--------------------------------
|
||||
|
||||
This release is a branch of the 2.0.1 release.
|
||||
|
||||
Moving to `reStructured Text <http://docutils.sourceforge.net/rst.html>`_ for
|
||||
the documentation.
|
||||
|
||||
Fixed problem with ``fail()``. The failure message was not properly printed.
|
||||
|
||||
Fixed the ``Makefile`` so that the DocBook XML and XSLT files would be
|
||||
downloaded before parsing can continue.
|
||||
|
||||
Renamed the internal ``__SHUNIT_TRUE`` and ``__SHUNIT_FALSE`` variables to
|
||||
``SHUNIT_TRUE`` and ``SHUNIT_FALSE`` so that unit tests can "use" them.
|
||||
|
||||
Added support for test "skipping". If skipping is turned on with the
|
||||
``startSkip()`` function, ``assert`` and ``fail`` functions will return
|
||||
immediately, and the skip will be recorded.
|
||||
|
||||
The report output format was changed to include the percentage for each test
|
||||
result, rather than just those successful.
|
||||
|
||||
|
||||
.. $Revision$
|
||||
.. vim:fileencoding=latin1:ft=text:spell:tw=80
|
||||
212
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/README.txt
vendored
Normal file
212
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/README.txt
vendored
Normal file
@@ -0,0 +1,212 @@
|
||||
====================
|
||||
shUnit2 2.1.x README
|
||||
====================
|
||||
|
||||
code.google.com
|
||||
===============
|
||||
|
||||
This project is stored on code.google.com as http://code.google.com/p/shunit2/.
|
||||
All releases as of 2.1.4 and full source are available there. Documentation is
|
||||
included as part of the source and each release. Source code is stored in
|
||||
Subversion and can be accessed using the following information.
|
||||
|
||||
Browse the code in a web browser:
|
||||
|
||||
- http://code.google.com/p/shunit2/source/browse
|
||||
- svn > trunk > source > 2.1
|
||||
|
||||
Check out the code locally ::
|
||||
|
||||
$ svn checkout http://shunit2.googlecode.com/svn/trunk/ shflags-read-only
|
||||
|
||||
|
||||
SourceForge
|
||||
===========
|
||||
|
||||
DEPRECATED
|
||||
|
||||
This project is stored on SourceForge as http://sf.net/projects/shunit2. The
|
||||
source code is stored in Subversion and can be accessed using the following
|
||||
information.
|
||||
|
||||
Check out the code locally ::
|
||||
|
||||
$ svn co https://shunit2.svn.sourceforge.net/svnroot/shunit2/trunk/source/2.1 shunit2
|
||||
|
||||
Browse the code in a web browser:
|
||||
|
||||
- http://shunit2.svn.sourceforge.net/viewvc/shunit2/trunk/source/2.1/
|
||||
- http://shunit2.svn.sourceforge.net/svnroot/shunit2/trunk/source/2.1/
|
||||
|
||||
|
||||
Making a release
|
||||
================
|
||||
|
||||
For these steps, it is assumed we are working with release 2.0.0.
|
||||
|
||||
Steps:
|
||||
|
||||
- write release notes
|
||||
- update version
|
||||
- finish changelog
|
||||
- check all the code in
|
||||
- tag the release
|
||||
- export the release
|
||||
- create tarball
|
||||
- md5sum the tarball and sign with gpg
|
||||
- update website
|
||||
- post to SourceForge and Freshmeat
|
||||
|
||||
Write Release Notes
|
||||
-------------------
|
||||
|
||||
This should be pretty self explanatory. Use one of the release notes from a
|
||||
previous release as an example.
|
||||
|
||||
The versions of the various platforms and shells are included when the
|
||||
master unit test script is run, or when ``bin/gen_test_results.sh`` is
|
||||
used. To determine the versions of the installed shells by hand, use the
|
||||
``lib/versions`` script.
|
||||
|
||||
Alternatively, do the following:
|
||||
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| Shell | OS | Notes |
|
||||
+=======+=========+===========================================================+
|
||||
| bash | | ``$ bash --version`` |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| dash | Linux | ``$ dpkg -l |grep dash`` |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| ksh | | ``$ ksh --version`` |
|
||||
| | | -or- |
|
||||
| | | ``$ echo 'echo $KSH_VERSION' |ksh`` |
|
||||
| +---------+-----------------------------------------------------------+
|
||||
| | Cygwin | see pdksh |
|
||||
| +---------+-----------------------------------------------------------+
|
||||
| | Solaris | ``$ strings /usr/bin/ksh |grep 'Version'`` |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| pdksh | | ``$ strings /bin/pdksh |grep 'PD KSH'`` |
|
||||
| +---------+-----------------------------------------------------------+
|
||||
| | Cygwin | look in the downloaded Cygwin directory |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| sh | Solaris | not possible |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
| zsh | | ``$ zsh --version`` |
|
||||
+-------+---------+-----------------------------------------------------------+
|
||||
|
||||
Update Version
|
||||
--------------
|
||||
|
||||
Edit ``src/shell/shunit2`` and change the version number in the comment, as well
|
||||
as in the ``SHUNIT_VERSION`` variable.
|
||||
|
||||
Finish Documentation
|
||||
--------------------
|
||||
|
||||
Make sure that any remaining changes get put into the ``CHANGES-X.X.txt`` file.
|
||||
|
||||
Finish writing the ``RELEASE_NOTES-X.X.X.txt``. If necessary, run it
|
||||
through the **fmt** command to make it pretty (hopefully it is already). ::
|
||||
|
||||
$ fmt -w 80 RELEASE_NOTES-2.0.0.txt >RELEASE_NOTES-2.0.0.txt.new
|
||||
$ mv RELEASE_NOTES-2.0.0.txt.new RELEASE_NOTES-2.0.0.txt
|
||||
|
||||
We want to have an up-to-date version of the documentation in the release, so
|
||||
we'd better build it. ::
|
||||
|
||||
$ pwd
|
||||
.../shunit2/source/2.1
|
||||
$ cd doc
|
||||
$ RST2HTML_OPTS='--stylesheet-path=rst2html.css'
|
||||
$ rst2html ${RST2HTML_OPTS} shunit2.txt >shunit2.html
|
||||
|
||||
Check In All the Code
|
||||
---------------------
|
||||
|
||||
This step is pretty self-explanatory ::
|
||||
|
||||
$ pwd
|
||||
.../shunit2/source/2.0
|
||||
$ svn ci -m "finalizing release"
|
||||
|
||||
Tag the Release
|
||||
---------------
|
||||
::
|
||||
|
||||
$ pwd
|
||||
.../shunit2/source
|
||||
$ ls
|
||||
2.0 2.1
|
||||
$ svn cp -m "Release 2.0.0" 2.0 https://shunit2.googlecode.com/svn/tags/source/2.0.0
|
||||
|
||||
Export the Release
|
||||
------------------
|
||||
::
|
||||
|
||||
$ pwd
|
||||
.../shunit2/builds
|
||||
$ svn export https://shunit2.googlecode.com/svn/tags/source/2.0.0 shunit2-2.0.0
|
||||
|
||||
Create Tarball
|
||||
--------------
|
||||
::
|
||||
|
||||
$ tar cfz ../releases/shunit2-2.0.0.tgz shunit2-2.0.0
|
||||
|
||||
Sign the Tarball with gpg
|
||||
-------------------------
|
||||
::
|
||||
|
||||
$ cd ../releases
|
||||
$ gpg --default-key kate.ward@forestent.com --detach-sign shunit2-2.0.0.tgz
|
||||
|
||||
Update Website
|
||||
--------------
|
||||
|
||||
Again, pretty self-explanatory. Make sure to copy the GPG signature file. Once
|
||||
done, make sure to tag the website so we can go back in time if needed. ::
|
||||
|
||||
$ pwd
|
||||
.../shunit2
|
||||
$ ls
|
||||
source website
|
||||
$ svn cp -m "Release 2.0.0" \
|
||||
website https://shunit2.googlecode.com/svn/tags/website/20060916
|
||||
|
||||
Now, update the website. It too is held in Subversion, so **ssh** into the web
|
||||
server and use ``svn up`` to grab the latest version.
|
||||
|
||||
Post to code.google.com and Freshmeat
|
||||
-------------------------------------
|
||||
|
||||
- http://code.google.com/p/shunit2/
|
||||
- http://freshmeat.net/
|
||||
|
||||
|
||||
Related Documentation
|
||||
=====================
|
||||
|
||||
Docbook:
|
||||
http://www.docbook.org/
|
||||
|
||||
Docbook XML
|
||||
docbook-xml-4.4.zip:
|
||||
http://www.docbook.org/xml/4.4/docbook-xml-4.4.zip
|
||||
http://www.oasis-open.org/docbook/xml/4.4/docbook-xml-4.4.zip
|
||||
docbook-xml-4.5.zip:
|
||||
http://www.docbook.org/xml/4.5/docbook-xml-4.5.zip
|
||||
Docbook XSL
|
||||
docbook-xsl-1.71.0.tar.bz2:
|
||||
http://prdownloads.sourceforge.net/docbook/docbook-xsl-1.71.0.tar.bz2?download
|
||||
docbook-xsl-1.71.1.tar.bz2:
|
||||
http://downloads.sourceforge.net/docbook/docbook-xsl-1.71.1.tar.bz2?use_mirror=puzzle
|
||||
JUnit:
|
||||
http://www.junit.org/
|
||||
reStructuredText:
|
||||
http://docutils.sourceforge.net/docs/user/rst/quickstart.html
|
||||
|
||||
.. generate HTML using rst2html from Docutils of
|
||||
.. http://docutils.sourceforge.net/
|
||||
..
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:tw=80
|
||||
.. $Revision$
|
||||
104
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.0.txt
vendored
Normal file
104
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.0.txt
vendored
Normal file
@@ -0,0 +1,104 @@
|
||||
Release Notes for shUnit2 2.1.0
|
||||
===============================
|
||||
|
||||
This release was branched from shUnit2 2.0.1. It mostly adds new functionality,
|
||||
but there are couple of bugs fixed from the previous release.
|
||||
|
||||
See the ``CHANGES-2.1.rst`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
This list of platforms comes from the latest version of log4sh as shUnit2 is
|
||||
used in the testing of log4sh on each of these platforms.
|
||||
|
||||
Cygwin
|
||||
|
||||
- bash 3.2.9(10)
|
||||
- pdksh 5.2.14
|
||||
|
||||
Linux
|
||||
|
||||
- bash 3.1.17(1), 3.2.10(1)
|
||||
- dash 0.5.3
|
||||
- ksh 1993-12-28
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.2 (does not work)
|
||||
|
||||
Mac OS X 10.4.8 (Darwin 8.8)
|
||||
|
||||
- bash 2.05b.0(1)
|
||||
- ksh 1993-12-28
|
||||
|
||||
Solaris 8 U3 (x86)
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.03.0(1)
|
||||
- ksh M-11/16/88i
|
||||
|
||||
Solaris 10 U2 (sparc)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.00.16(1)
|
||||
- ksh M-11/16/88i
|
||||
|
||||
Solaris 10 U2 (x86)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.00.16(1)
|
||||
- ksh M-11/16/88i
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
Test skipping
|
||||
|
||||
Support added for test "skipping". A skip mode can be enabled so that
|
||||
subsequent ``assert`` and ``fail`` functions that are called will be recorded
|
||||
as "skipped" rather than as "passed" or "failed". This functionality can be
|
||||
used such that when a set of tests makes sense on one platform but not on
|
||||
another, they can be effectively disabled without altering the total number
|
||||
of tests.
|
||||
|
||||
One example might be when something is supported under ``bash``, but not
|
||||
under a standard Bourne shell.
|
||||
|
||||
New functions: ``startSkipping()``, ``endSkipping``, ``isSkipping``
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Moving to the use of `reStructured Text
|
||||
<http://docutils.sourceforge.net/rst.html>`_ for documentation. It is easy to
|
||||
read and edit in textual form, but converts nicely to HTML.
|
||||
|
||||
The report format has changed. Rather than including a simple "success"
|
||||
percentage at the end, a percentage is given for each type of test.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
The ``fail()`` function did not output the optional failure message.
|
||||
|
||||
Fixed the ``Makefile`` so that the DocBook XML and XSLT files would be
|
||||
downloaded before documentation parsing will continue.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
.. $Revision$
|
||||
.. vim:fileencoding=latin1:spell:syntax=rst:textwidth=80
|
||||
88
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.1.txt
vendored
Normal file
88
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.1.txt
vendored
Normal file
@@ -0,0 +1,88 @@
|
||||
Release Notes for shUnit2 2.1.1
|
||||
===============================
|
||||
|
||||
This is mainly a bug fix release, but it also incorporates a realignment with
|
||||
the JUnit 4 code. Asserts now provide better failure messages, and the failure
|
||||
functions no longer perform tests.
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
This list of platforms comes from the latest version of log4sh as shUnit2 is
|
||||
used in the testing of log4sh on each of these platforms.
|
||||
|
||||
Cygwin
|
||||
|
||||
- bash 3.2.15(13)
|
||||
- pdksh 5.2.14
|
||||
|
||||
Linux
|
||||
|
||||
- bash 3.1.17(1), 3.2.10(1)
|
||||
- dash 0.5.3
|
||||
- ksh 1993-12-28
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.2 (does not work)
|
||||
|
||||
Mac OS X 10.4.9 (Darwin 8.9.1)
|
||||
|
||||
- bash 2.05b.0(1)
|
||||
- ksh 1993-12-28
|
||||
|
||||
Solaris 8 U3 (x86)
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.03.0(1)
|
||||
- ksh M-11/16/88i
|
||||
|
||||
Solaris 10 U2 (sparc, x86)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.00.16(1)
|
||||
- ksh M-11/16/88i
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
The internal test in ``assertFalse()`` now accepts any non-zero value as false.
|
||||
|
||||
The ``assertTrue()`` and ``assertFalse()`` functions now accept an integer value
|
||||
for a conditional test. A value of '0' is considered 'true', while any non-zero
|
||||
value is considered 'false'.
|
||||
|
||||
Self-testing unit tests were added.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
The ``fail()`` assert now honors skipping.
|
||||
|
||||
The ``docs-docbook-prep`` target now works properly.
|
||||
|
||||
All asserts now properly unset their variables.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
Functions do not properly test for an invalid number of arguments.
|
||||
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:textwidth=80
|
||||
83
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.2.txt
vendored
Normal file
83
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.2.txt
vendored
Normal file
@@ -0,0 +1,83 @@
|
||||
Release Notes for shUnit2 2.1.2
|
||||
===============================
|
||||
|
||||
This release adds initial support for the zsh shell. Due to some differences
|
||||
with this shell as compared with others, some special checks have been added,
|
||||
and there are some extra requirements necessary when this shell is to be used.
|
||||
|
||||
To use zsh with shUnit2, the following two requirements must be met:
|
||||
* The ``shwordsplit`` option must be set.
|
||||
* The ``function_argzero`` option must be unset.
|
||||
|
||||
Please read the Shell Errata section of the documentation for guidance on how
|
||||
to meet these requirements.
|
||||
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
This list of platforms comes from the latest version of log4sh as shUnit2 is
|
||||
used in the testing of log4sh on each of these platforms.
|
||||
|
||||
Linux
|
||||
|
||||
- bash 3.1.17(1), 3.2.25(1)
|
||||
- dash 0.5.4
|
||||
- ksh 1993-12-28
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.2.5, 4.3.4
|
||||
|
||||
Mac OS X 10.4.11 (Darwin 8.11.1)
|
||||
|
||||
- bash 2.05b.0(1)
|
||||
- ksh 1993-12-28
|
||||
- zsh 4.2.3
|
||||
|
||||
Solaris 10 U3 (x86)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.00.16(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 4.2.1
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
Support for the zsh shell.
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Added some argument count checks.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
Functions do not properly test for an invalid number of arguments.
|
||||
|
||||
ksh and pdksh do not pass null arguments (i.e. empty strings as '') properly,
|
||||
and as such checks do not work properly.
|
||||
|
||||
zsh requires the ``shwordsplit`` option to be set, and the ``function_argzero``
|
||||
option to be unset for proper operation.
|
||||
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:textwidth=80
|
||||
84
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.3.txt
vendored
Normal file
84
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.3.txt
vendored
Normal file
@@ -0,0 +1,84 @@
|
||||
Release Notes for shUnit2 2.1.3
|
||||
===============================
|
||||
|
||||
This release is minor feature release. It improves support for zsh (although it
|
||||
still isn't what it could be) and adds automated testing framework support by
|
||||
returning a non-zero exit when tests fail.
|
||||
|
||||
To use zsh with shUnit2, the following two requirements must be met:
|
||||
* The ``shwordsplit`` option must be set.
|
||||
* The ``function_argzero`` option must be unset.
|
||||
|
||||
Please read the Shell Errata section of the documentation for guidance on how
|
||||
to meet these requirements.
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
Cygwin
|
||||
|
||||
- bash 3.2.33(18)
|
||||
- pdksh 5.2.14
|
||||
|
||||
Linux
|
||||
|
||||
- bash 3.2.33(1)
|
||||
- dash 0.5.4
|
||||
- ksh 1993-12-28
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.4
|
||||
|
||||
Mac OS X 10.5.2 (Darwin 9.2.2)
|
||||
|
||||
- bash 3.2.17(1)
|
||||
- ksh 1993-12-28
|
||||
- zsh 4.3.4
|
||||
|
||||
Solaris 11 x86 (Nevada 77)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.2.25(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 4.3.4
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Support for automated testing frameworks.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
Fixed some issues with zsh support.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
Functions do not properly test for an invalid number of arguments.
|
||||
|
||||
ksh and pdksh do not pass null arguments (i.e. empty strings as '') properly,
|
||||
and as such checks do not work properly.
|
||||
|
||||
zsh requires the ``shwordsplit`` option to be set, and the ``function_argzero``
|
||||
option to be unset for proper operation.
|
||||
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:textwidth=80
|
||||
100
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.4.txt
vendored
Normal file
100
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.4.txt
vendored
Normal file
@@ -0,0 +1,100 @@
|
||||
Release Notes for shUnit2 2.1.4
|
||||
===============================
|
||||
|
||||
This release contains lots of bug fixes and changes. Mostly, it fixes zsh
|
||||
support in zsh 3.0, and the handling of null values in ksh.
|
||||
|
||||
To use zsh with shUnit2, the following requirement must be met:
|
||||
|
||||
- The ``shwordsplit`` option must be set.
|
||||
|
||||
Please read the Shell Errata section of the documentation for guidance on how
|
||||
to meet these requirements.
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
Cygwin
|
||||
|
||||
- bash 3.2.39(19)
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.4
|
||||
|
||||
Linux (Ubuntu Dapper 6.06)
|
||||
|
||||
- bash 3.1.17(1)
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.2.5
|
||||
|
||||
Linux (Ubuntu Hardy 8.04)
|
||||
|
||||
- bash 3.2.39(1)
|
||||
- dash 0.5.4
|
||||
- ksh 1993-12-28
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.4
|
||||
|
||||
Mac OS X 10.5.4 (Darwin 9.4.0)
|
||||
|
||||
- bash 3.2.17(1)
|
||||
- ksh 1993-12-28
|
||||
- zsh 4.3.4
|
||||
|
||||
Solaris 9 U6 x86
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.05.0(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 3.0.8
|
||||
|
||||
Solaris 11 x86 (Nevada 77)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.2.25(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 4.3.4
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
Support added to output assert source line number as part of assert messages.
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Support for automated testing frameworks.
|
||||
|
||||
Added argument count error checking to all functions.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
Fixed some issues with ksh and zsh support.
|
||||
|
||||
Fixed off-by-one of exit value in trap handler.
|
||||
|
||||
Fixed handling of null values under ksh.
|
||||
|
||||
Fixed bug in last resort temporary directory creation.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
zsh requires the ``shwordsplit`` option to be set.
|
||||
|
||||
Line numbers in assert messages do not work properly with Bash 2.x.
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:tw=80
|
||||
128
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.5.txt
vendored
Normal file
128
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.5.txt
vendored
Normal file
@@ -0,0 +1,128 @@
|
||||
Release Notes for shUnit2 2.1.5
|
||||
===============================
|
||||
|
||||
This release contains several bug fixes and changes. Additionally, it includes
|
||||
a rewrite of the test output to better match JUnit and PyUnit.
|
||||
|
||||
This version also includes a slightly expanded set of coding standards by which
|
||||
shUnit2 is coded. It should help anyone reading the code to better understand
|
||||
it.
|
||||
|
||||
|
||||
|
||||
Please read the Shell Errata section of the documentation for guidance on how
|
||||
to meet these requirements.
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
Cygwin
|
||||
|
||||
- bash 3.2.39(20)
|
||||
- ksh (sym-link to pdksh)
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.4
|
||||
|
||||
Linux (Ubuntu Dapper 6.06)
|
||||
|
||||
- bash 3.1.17(1)
|
||||
- ksh M-1993-12-28
|
||||
- pdksh 5.2.14-99/07/13.2
|
||||
- zsh 4.2.5
|
||||
|
||||
Linux (Ubuntu Hardy 8.04)
|
||||
|
||||
- bash 3.2.39(1)
|
||||
- dash 0.5.4
|
||||
- ksh M-1993-12-28
|
||||
- pdksh 5.2.14-99/07/13.2
|
||||
- zsh 4.3.4
|
||||
|
||||
Mac OS X 10.5.4 (Darwin 9.4.0)
|
||||
|
||||
- bash 3.2.17(1)
|
||||
- ksh M-1993-12-28
|
||||
- zsh 4.3.4
|
||||
|
||||
Solaris 9 U6 x86
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.05.0(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 3.0.8
|
||||
|
||||
Solaris 11 x86 (Nevada 77)
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.2.25(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 4.3.4
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
Support added for output assert source line number as part of assert messages.
|
||||
|
||||
Issue #2: Added assertNotEquals() assert.
|
||||
|
||||
Provided a public ``shunit_tmpDir`` variable that can be used by unit test
|
||||
scripts that need automated and guaranteed cleanup.
|
||||
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Issue #3: Removed the check for unset variables as shUnit2 should not expect
|
||||
scripts being tested to be clean.
|
||||
|
||||
Issue #4: Rewrote the test summary. It is now greatly simplified and much more
|
||||
script friendly.
|
||||
|
||||
Issue #5: Fixed the documentation around the usage of failures.
|
||||
|
||||
Issue #9: Added unit tests and improved documentation around the use of macros.
|
||||
|
||||
Code updated to meet documented coding standards.
|
||||
|
||||
Improved code reuse of ``_shunit_exit()`` and ``_shunit_fatal()`` functions.
|
||||
|
||||
All output except shUnit2 error messages now goes to STDOUT.
|
||||
|
||||
Converted DocBook documentation to reStructuredText for easier maintenance.
|
||||
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
Issue #1: Fixed bug in rap code where certain types of exit conditions did not
|
||||
generate the ending report.
|
||||
|
||||
Issue #7: Fixed duplicated printing of messages passed to asserts.
|
||||
|
||||
Fixed bugs in ``shlib_relToAbsPath()`` in ``shlib``.
|
||||
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
Zsh requires the ``shwordsplit`` option to be set. See the documentation for
|
||||
examples of how to do this.
|
||||
|
||||
Line numbers in assert messages do not work properly with BASH 2.x.
|
||||
|
||||
The Bourne shell of Solaris, BASH 2.x, and Zsh 3.0.x do not properly catch the
|
||||
SIGTERM signal. As such, shell interpreter failures due to such things as
|
||||
unbound variables cannot be caught. (See ``shunit_test_misc.sh``)
|
||||
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:tw=80
|
||||
112
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.6.txt
vendored
Normal file
112
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/RELEASE_NOTES-2.1.6.txt
vendored
Normal file
@@ -0,0 +1,112 @@
|
||||
Release Notes for shUnit2 2.1.6
|
||||
===============================
|
||||
|
||||
This release contains bug fixes and changes. It is also the first release to
|
||||
support running shunit2 as a standalone program.
|
||||
|
||||
Please read the Shell Errata section of the documentation for guidance on how
|
||||
to meet these requirements.
|
||||
|
||||
See the ``CHANGES-2.1.txt`` file for a full list of changes.
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
Support for running shUnit2 as a standalone program. This makes it possible for
|
||||
users to execute their unit tests in a manner that is not dependent on the
|
||||
location an OS distribution maintainer chose to place shUnit2 in the file
|
||||
system.
|
||||
|
||||
Added support for functions defined like 'function someFunction()'.
|
||||
|
||||
Changes and Enhancements
|
||||
------------------------
|
||||
|
||||
Renamed the public ``shunit_tmpDir`` variable to ``SHUNIT_TMPDIR`` to be more
|
||||
consistent with the ``TMPDIR`` variable.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
Fixed issue where shunit2 would fail on some distributions when creating a
|
||||
temporary directory because the **od** command was not present.
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
None.
|
||||
|
||||
Known Bugs and Issues
|
||||
---------------------
|
||||
|
||||
Zsh requires the ``shwordsplit`` option to be set. See the documentation for
|
||||
examples of how to do this.
|
||||
|
||||
Line numbers in assert messages do not work properly with BASH 2.x.
|
||||
|
||||
The Bourne shell of Solaris, BASH 2.x, and Zsh 3.0.x do not properly catch the
|
||||
SIGTERM signal. As such, shell interpreter failures due to such things as
|
||||
unbound variables cannot be caught. (See ``shunit_test_misc.sh``)
|
||||
|
||||
Tested Platforms
|
||||
----------------
|
||||
|
||||
Cygwin 1.7.9 (Windows XP SP2)
|
||||
|
||||
- bash 4.1.10(4)
|
||||
- dash 0.5.6.1
|
||||
- ksh (sym-link to pdksh)
|
||||
- pdksh 5.2.14
|
||||
- zsh 4.3.11
|
||||
|
||||
Linux (Ubuntu Dapper 6.06.2 LTS)
|
||||
|
||||
- bash 3.1.17(1)
|
||||
- dash 0.5.3
|
||||
- ksh (sym-link to pdksh)
|
||||
- pdksh 5.2.14-99/07/13.2
|
||||
- zsh 4.2.5
|
||||
|
||||
Linux (Ubuntu Hardy 8.04.4 LTS)
|
||||
|
||||
- bash 3.2.39(1)
|
||||
- dash 0.5.4
|
||||
- ksh M-1993-12-28
|
||||
- pdksh 5.2.14-99/07/13.2
|
||||
- zsh 4.3.4
|
||||
|
||||
Linux (Ubuntu Lucid 10.04.2 LTS)
|
||||
|
||||
- bash 4.1.5(1)
|
||||
- dash 0.5.5.1
|
||||
- ksh JM-93t+-2009-05-01
|
||||
- pdksh 5.2.14-99/07/13.2
|
||||
- zsh 4.3.10
|
||||
|
||||
Mac OS X 10.6.7
|
||||
|
||||
- bash 3.2.48(1)
|
||||
- ksh M-1993-12-28
|
||||
- zsh 4.3.9
|
||||
|
||||
Solaris 8 U7 x86
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.03.0(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 3.0.6
|
||||
|
||||
Solaris 9 U6 x86
|
||||
|
||||
- /bin/sh
|
||||
- bash 2.05.0(1)
|
||||
- ksh M-11/16/88i
|
||||
- zsh 3.0.8
|
||||
|
||||
OpenSolaris 2009.06(snv_111b) x86
|
||||
|
||||
- /bin/sh
|
||||
- bash 3.2.25(1)
|
||||
- ksh 2008-11-04
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:tw=80
|
||||
13
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/TODO.txt
vendored
Normal file
13
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/TODO.txt
vendored
Normal file
@@ -0,0 +1,13 @@
|
||||
Make it possible to execute a single test by passing the name of the test on
|
||||
the command line
|
||||
|
||||
Add support for '--randomize-order' so that the test order is randomized to
|
||||
check for dependencies (which shouldn't be there) between tests.
|
||||
|
||||
--debug option to display point in source code (line number and such) where the
|
||||
problem showed up.
|
||||
|
||||
assertTrue() just gives 'ASSERT:', nothing else :-(. others too?
|
||||
upd: assertNull() will give message passed, but nothing else useful :-(
|
||||
|
||||
$Revision$
|
||||
74
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/coding_standards.txt
vendored
Normal file
74
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/coding_standards.txt
vendored
Normal file
@@ -0,0 +1,74 @@
|
||||
Coding Standards
|
||||
================
|
||||
|
||||
Variable and Function Names
|
||||
---------------------------
|
||||
|
||||
All shUnit2 specific constants, variables, and functions will be prefixed
|
||||
appropriately with 'shunit'. This is to distinguish usage in the shUnit2 code
|
||||
from users own scripts so that the shell name space remains predictable to
|
||||
users. The exceptions here are the standard ``assertEquals``, etc. functions.
|
||||
|
||||
All non-builtin constants and variables will be surrouned with squiggle
|
||||
brackets, e.g. '${shunit_someVariable}' to improve code readability.
|
||||
|
||||
Due to some shells not supporting local variables in functions, care in the
|
||||
naming and use of variables, both public and private, is very important.
|
||||
Accidental overriding of the variables can occur easily if care is not taken as
|
||||
all variables are technically global variables in some shells.
|
||||
|
||||
+----------------------------------+---------------------------+
|
||||
| *type* | *sample* |
|
||||
+==================================+===========================+
|
||||
| global public constant | ``SHUNIT_TRUE`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| global private constant | ``__SHUNIT_SHELL_FLAGS`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| global public variable | not used |
|
||||
+----------------------------------+---------------------------+
|
||||
| global private variable | ``__shunit_someVariable`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| global macro | ``_SHUNIT_SOME_MACRO_`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| public function | ``assertEquals`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| public function, local variable | ``shunit_someVariable_`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| private function | ``_shunit_someFunction`` |
|
||||
+----------------------------------+---------------------------+
|
||||
| private function, local variable | ``_shunit_someVariable_`` |
|
||||
+----------------------------------+---------------------------+
|
||||
|
||||
Where it makes sense, variables can have the first letter of the second and
|
||||
later words capitalized. For example, the local variable name for the total
|
||||
number of test cases seen might be ``shunit_totalTestsSeen_``.
|
||||
|
||||
Local Variable Cleanup
|
||||
----------------------
|
||||
|
||||
As many shells do not support local variables, no support for cleanup of
|
||||
variables is present either. As such, all variables local to a function must be
|
||||
cleared up with the ``unset`` command at the end of each function.
|
||||
|
||||
Indentation
|
||||
-----------
|
||||
|
||||
Code block indentation is two (2) spaces, and tabs may not be used. ::
|
||||
|
||||
if [ -z 'some string' ]; then
|
||||
someFunction
|
||||
fi
|
||||
|
||||
Lines of code should be no longer than 80 characters unless absolutely
|
||||
necessary. When lines are wrapped using the backslash character '\', subsequent
|
||||
lines should be indented with four (4) spaces so as to differentiate from the
|
||||
standard spacing of two characters. Tabs may *not* be used. ::
|
||||
|
||||
for x in some set of very long set of arguments that make for a very long \
|
||||
that extends much too long for one line
|
||||
do
|
||||
echo ${x}
|
||||
done
|
||||
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:tw=80
|
||||
.. $Revision$
|
||||
14
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/contributors.txt
vendored
Normal file
14
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/contributors.txt
vendored
Normal file
@@ -0,0 +1,14 @@
|
||||
The original author of shunit2 is Kate Ward. The following people have
|
||||
contributed in some way or another to shunit2.
|
||||
|
||||
Bryan Larsen
|
||||
Kevin Van Horn
|
||||
Maciej Bliziński
|
||||
Mario Sparada
|
||||
Mathias Goldau
|
||||
Richard Jensen
|
||||
Rob Holland
|
||||
Rocky Bernstein
|
||||
wood4321 (of code.google.com)
|
||||
|
||||
$Revision$
|
||||
34
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/design_doc.txt
vendored
Normal file
34
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/design_doc.txt
vendored
Normal file
@@ -0,0 +1,34 @@
|
||||
Design Doc for shUnit
|
||||
|
||||
shUnit is based upon JUnit. The initial ideas for the script came from the book
|
||||
"Pragmatic Unit Testing - In Java with JUnit" by Andrew Hunt and David Thomas.
|
||||
|
||||
The script was written to perform unit testing for log4sh. log4sh had grown
|
||||
enough that it was becoming difficult to easily test and and verify that the
|
||||
tests passed for the many different operating systems on which it was being
|
||||
used.
|
||||
|
||||
The functions in shUnit are meant to match those in JUnit as much as possible
|
||||
where shell allows. In the initial version, there will be no concept of
|
||||
exceptions (as normal POSIX shell has no concept of them) but attempts to trap
|
||||
problems will be done.
|
||||
|
||||
Programatic Standards:
|
||||
|
||||
* SHUNIT_TRUE - public global constant
|
||||
* __SHUNIT_SHELL_FLAGS - private global constant
|
||||
* __shunit_oldShellFlags - private global variable
|
||||
|
||||
* assertEquals - public unit test function
|
||||
* shunit_publicFunc - public shUnit function; can be called from parent unit
|
||||
test script
|
||||
* _shunit_privateFunc - private shUnit function; should not be called from
|
||||
parent script. meant for internal use by shUnit
|
||||
|
||||
* _su_myVar - variable inside a public function. prefixing with '_su_' to
|
||||
reduce the chances that a variable outside of shUnit will be overridden.
|
||||
* _su__myVar - variable inside a private function. prefixing with '_su__' to
|
||||
reduce the chances that a variable in a shUnit public function, or a variable
|
||||
outside of shUnit will be overridden.
|
||||
|
||||
$Revision$
|
||||
502
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/lgpl-2.1.txt
vendored
Normal file
502
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/lgpl-2.1.txt
vendored
Normal file
@@ -0,0 +1,502 @@
|
||||
GNU LESSER GENERAL PUBLIC LICENSE
|
||||
Version 2.1, February 1999
|
||||
|
||||
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
[This is the first released version of the Lesser GPL. It also counts
|
||||
as the successor of the GNU Library Public License, version 2, hence
|
||||
the version number 2.1.]
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
Licenses are intended to guarantee your freedom to share and change
|
||||
free software--to make sure the software is free for all its users.
|
||||
|
||||
This license, the Lesser General Public License, applies to some
|
||||
specially designated software packages--typically libraries--of the
|
||||
Free Software Foundation and other authors who decide to use it. You
|
||||
can use it too, but we suggest you first think carefully about whether
|
||||
this license or the ordinary General Public License is the better
|
||||
strategy to use in any particular case, based on the explanations below.
|
||||
|
||||
When we speak of free software, we are referring to freedom of use,
|
||||
not price. Our General Public Licenses are designed to make sure that
|
||||
you have the freedom to distribute copies of free software (and charge
|
||||
for this service if you wish); that you receive source code or can get
|
||||
it if you want it; that you can change the software and use pieces of
|
||||
it in new free programs; and that you are informed that you can do
|
||||
these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
distributors to deny you these rights or to ask you to surrender these
|
||||
rights. These restrictions translate to certain responsibilities for
|
||||
you if you distribute copies of the library or if you modify it.
|
||||
|
||||
For example, if you distribute copies of the library, whether gratis
|
||||
or for a fee, you must give the recipients all the rights that we gave
|
||||
you. You must make sure that they, too, receive or can get the source
|
||||
code. If you link other code with the library, you must provide
|
||||
complete object files to the recipients, so that they can relink them
|
||||
with the library after making changes to the library and recompiling
|
||||
it. And you must show them these terms so they know their rights.
|
||||
|
||||
We protect your rights with a two-step method: (1) we copyright the
|
||||
library, and (2) we offer you this license, which gives you legal
|
||||
permission to copy, distribute and/or modify the library.
|
||||
|
||||
To protect each distributor, we want to make it very clear that
|
||||
there is no warranty for the free library. Also, if the library is
|
||||
modified by someone else and passed on, the recipients should know
|
||||
that what they have is not the original version, so that the original
|
||||
author's reputation will not be affected by problems that might be
|
||||
introduced by others.
|
||||
|
||||
Finally, software patents pose a constant threat to the existence of
|
||||
any free program. We wish to make sure that a company cannot
|
||||
effectively restrict the users of a free program by obtaining a
|
||||
restrictive license from a patent holder. Therefore, we insist that
|
||||
any patent license obtained for a version of the library must be
|
||||
consistent with the full freedom of use specified in this license.
|
||||
|
||||
Most GNU software, including some libraries, is covered by the
|
||||
ordinary GNU General Public License. This license, the GNU Lesser
|
||||
General Public License, applies to certain designated libraries, and
|
||||
is quite different from the ordinary General Public License. We use
|
||||
this license for certain libraries in order to permit linking those
|
||||
libraries into non-free programs.
|
||||
|
||||
When a program is linked with a library, whether statically or using
|
||||
a shared library, the combination of the two is legally speaking a
|
||||
combined work, a derivative of the original library. The ordinary
|
||||
General Public License therefore permits such linking only if the
|
||||
entire combination fits its criteria of freedom. The Lesser General
|
||||
Public License permits more lax criteria for linking other code with
|
||||
the library.
|
||||
|
||||
We call this license the "Lesser" General Public License because it
|
||||
does Less to protect the user's freedom than the ordinary General
|
||||
Public License. It also provides other free software developers Less
|
||||
of an advantage over competing non-free programs. These disadvantages
|
||||
are the reason we use the ordinary General Public License for many
|
||||
libraries. However, the Lesser license provides advantages in certain
|
||||
special circumstances.
|
||||
|
||||
For example, on rare occasions, there may be a special need to
|
||||
encourage the widest possible use of a certain library, so that it becomes
|
||||
a de-facto standard. To achieve this, non-free programs must be
|
||||
allowed to use the library. A more frequent case is that a free
|
||||
library does the same job as widely used non-free libraries. In this
|
||||
case, there is little to gain by limiting the free library to free
|
||||
software only, so we use the Lesser General Public License.
|
||||
|
||||
In other cases, permission to use a particular library in non-free
|
||||
programs enables a greater number of people to use a large body of
|
||||
free software. For example, permission to use the GNU C Library in
|
||||
non-free programs enables many more people to use the whole GNU
|
||||
operating system, as well as its variant, the GNU/Linux operating
|
||||
system.
|
||||
|
||||
Although the Lesser General Public License is Less protective of the
|
||||
users' freedom, it does ensure that the user of a program that is
|
||||
linked with the Library has the freedom and the wherewithal to run
|
||||
that program using a modified version of the Library.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow. Pay close attention to the difference between a
|
||||
"work based on the library" and a "work that uses the library". The
|
||||
former contains code derived from the library, whereas the latter must
|
||||
be combined with the library in order to run.
|
||||
|
||||
GNU LESSER GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License Agreement applies to any software library or other
|
||||
program which contains a notice placed by the copyright holder or
|
||||
other authorized party saying it may be distributed under the terms of
|
||||
this Lesser General Public License (also called "this License").
|
||||
Each licensee is addressed as "you".
|
||||
|
||||
A "library" means a collection of software functions and/or data
|
||||
prepared so as to be conveniently linked with application programs
|
||||
(which use some of those functions and data) to form executables.
|
||||
|
||||
The "Library", below, refers to any such software library or work
|
||||
which has been distributed under these terms. A "work based on the
|
||||
Library" means either the Library or any derivative work under
|
||||
copyright law: that is to say, a work containing the Library or a
|
||||
portion of it, either verbatim or with modifications and/or translated
|
||||
straightforwardly into another language. (Hereinafter, translation is
|
||||
included without limitation in the term "modification".)
|
||||
|
||||
"Source code" for a work means the preferred form of the work for
|
||||
making modifications to it. For a library, complete source code means
|
||||
all the source code for all modules it contains, plus any associated
|
||||
interface definition files, plus the scripts used to control compilation
|
||||
and installation of the library.
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running a program using the Library is not restricted, and output from
|
||||
such a program is covered only if its contents constitute a work based
|
||||
on the Library (independent of the use of the Library in a tool for
|
||||
writing it). Whether that is true depends on what the Library does
|
||||
and what the program that uses the Library does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Library's
|
||||
complete source code as you receive it, in any medium, provided that
|
||||
you conspicuously and appropriately publish on each copy an
|
||||
appropriate copyright notice and disclaimer of warranty; keep intact
|
||||
all the notices that refer to this License and to the absence of any
|
||||
warranty; and distribute a copy of this License along with the
|
||||
Library.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy,
|
||||
and you may at your option offer warranty protection in exchange for a
|
||||
fee.
|
||||
|
||||
2. You may modify your copy or copies of the Library or any portion
|
||||
of it, thus forming a work based on the Library, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) The modified work must itself be a software library.
|
||||
|
||||
b) You must cause the files modified to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
c) You must cause the whole of the work to be licensed at no
|
||||
charge to all third parties under the terms of this License.
|
||||
|
||||
d) If a facility in the modified Library refers to a function or a
|
||||
table of data to be supplied by an application program that uses
|
||||
the facility, other than as an argument passed when the facility
|
||||
is invoked, then you must make a good faith effort to ensure that,
|
||||
in the event an application does not supply such function or
|
||||
table, the facility still operates, and performs whatever part of
|
||||
its purpose remains meaningful.
|
||||
|
||||
(For example, a function in a library to compute square roots has
|
||||
a purpose that is entirely well-defined independent of the
|
||||
application. Therefore, Subsection 2d requires that any
|
||||
application-supplied function or table used by this function must
|
||||
be optional: if the application does not supply it, the square
|
||||
root function must still compute square roots.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Library,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Library, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote
|
||||
it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Library.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Library
|
||||
with the Library (or with a work based on the Library) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may opt to apply the terms of the ordinary GNU General Public
|
||||
License instead of this License to a given copy of the Library. To do
|
||||
this, you must alter all the notices that refer to this License, so
|
||||
that they refer to the ordinary GNU General Public License, version 2,
|
||||
instead of to this License. (If a newer version than version 2 of the
|
||||
ordinary GNU General Public License has appeared, then you can specify
|
||||
that version instead if you wish.) Do not make any other change in
|
||||
these notices.
|
||||
|
||||
Once this change is made in a given copy, it is irreversible for
|
||||
that copy, so the ordinary GNU General Public License applies to all
|
||||
subsequent copies and derivative works made from that copy.
|
||||
|
||||
This option is useful when you wish to copy part of the code of
|
||||
the Library into a program that is not a library.
|
||||
|
||||
4. You may copy and distribute the Library (or a portion or
|
||||
derivative of it, under Section 2) in object code or executable form
|
||||
under the terms of Sections 1 and 2 above provided that you accompany
|
||||
it with the complete corresponding machine-readable source code, which
|
||||
must be distributed under the terms of Sections 1 and 2 above on a
|
||||
medium customarily used for software interchange.
|
||||
|
||||
If distribution of object code is made by offering access to copy
|
||||
from a designated place, then offering equivalent access to copy the
|
||||
source code from the same place satisfies the requirement to
|
||||
distribute the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
5. A program that contains no derivative of any portion of the
|
||||
Library, but is designed to work with the Library by being compiled or
|
||||
linked with it, is called a "work that uses the Library". Such a
|
||||
work, in isolation, is not a derivative work of the Library, and
|
||||
therefore falls outside the scope of this License.
|
||||
|
||||
However, linking a "work that uses the Library" with the Library
|
||||
creates an executable that is a derivative of the Library (because it
|
||||
contains portions of the Library), rather than a "work that uses the
|
||||
library". The executable is therefore covered by this License.
|
||||
Section 6 states terms for distribution of such executables.
|
||||
|
||||
When a "work that uses the Library" uses material from a header file
|
||||
that is part of the Library, the object code for the work may be a
|
||||
derivative work of the Library even though the source code is not.
|
||||
Whether this is true is especially significant if the work can be
|
||||
linked without the Library, or if the work is itself a library. The
|
||||
threshold for this to be true is not precisely defined by law.
|
||||
|
||||
If such an object file uses only numerical parameters, data
|
||||
structure layouts and accessors, and small macros and small inline
|
||||
functions (ten lines or less in length), then the use of the object
|
||||
file is unrestricted, regardless of whether it is legally a derivative
|
||||
work. (Executables containing this object code plus portions of the
|
||||
Library will still fall under Section 6.)
|
||||
|
||||
Otherwise, if the work is a derivative of the Library, you may
|
||||
distribute the object code for the work under the terms of Section 6.
|
||||
Any executables containing that work also fall under Section 6,
|
||||
whether or not they are linked directly with the Library itself.
|
||||
|
||||
6. As an exception to the Sections above, you may also combine or
|
||||
link a "work that uses the Library" with the Library to produce a
|
||||
work containing portions of the Library, and distribute that work
|
||||
under terms of your choice, provided that the terms permit
|
||||
modification of the work for the customer's own use and reverse
|
||||
engineering for debugging such modifications.
|
||||
|
||||
You must give prominent notice with each copy of the work that the
|
||||
Library is used in it and that the Library and its use are covered by
|
||||
this License. You must supply a copy of this License. If the work
|
||||
during execution displays copyright notices, you must include the
|
||||
copyright notice for the Library among them, as well as a reference
|
||||
directing the user to the copy of this License. Also, you must do one
|
||||
of these things:
|
||||
|
||||
a) Accompany the work with the complete corresponding
|
||||
machine-readable source code for the Library including whatever
|
||||
changes were used in the work (which must be distributed under
|
||||
Sections 1 and 2 above); and, if the work is an executable linked
|
||||
with the Library, with the complete machine-readable "work that
|
||||
uses the Library", as object code and/or source code, so that the
|
||||
user can modify the Library and then relink to produce a modified
|
||||
executable containing the modified Library. (It is understood
|
||||
that the user who changes the contents of definitions files in the
|
||||
Library will not necessarily be able to recompile the application
|
||||
to use the modified definitions.)
|
||||
|
||||
b) Use a suitable shared library mechanism for linking with the
|
||||
Library. A suitable mechanism is one that (1) uses at run time a
|
||||
copy of the library already present on the user's computer system,
|
||||
rather than copying library functions into the executable, and (2)
|
||||
will operate properly with a modified version of the library, if
|
||||
the user installs one, as long as the modified version is
|
||||
interface-compatible with the version that the work was made with.
|
||||
|
||||
c) Accompany the work with a written offer, valid for at
|
||||
least three years, to give the same user the materials
|
||||
specified in Subsection 6a, above, for a charge no more
|
||||
than the cost of performing this distribution.
|
||||
|
||||
d) If distribution of the work is made by offering access to copy
|
||||
from a designated place, offer equivalent access to copy the above
|
||||
specified materials from the same place.
|
||||
|
||||
e) Verify that the user has already received a copy of these
|
||||
materials or that you have already sent this user a copy.
|
||||
|
||||
For an executable, the required form of the "work that uses the
|
||||
Library" must include any data and utility programs needed for
|
||||
reproducing the executable from it. However, as a special exception,
|
||||
the materials to be distributed need not include anything that is
|
||||
normally distributed (in either source or binary form) with the major
|
||||
components (compiler, kernel, and so on) of the operating system on
|
||||
which the executable runs, unless that component itself accompanies
|
||||
the executable.
|
||||
|
||||
It may happen that this requirement contradicts the license
|
||||
restrictions of other proprietary libraries that do not normally
|
||||
accompany the operating system. Such a contradiction means you cannot
|
||||
use both them and the Library together in an executable that you
|
||||
distribute.
|
||||
|
||||
7. You may place library facilities that are a work based on the
|
||||
Library side-by-side in a single library together with other library
|
||||
facilities not covered by this License, and distribute such a combined
|
||||
library, provided that the separate distribution of the work based on
|
||||
the Library and of the other library facilities is otherwise
|
||||
permitted, and provided that you do these two things:
|
||||
|
||||
a) Accompany the combined library with a copy of the same work
|
||||
based on the Library, uncombined with any other library
|
||||
facilities. This must be distributed under the terms of the
|
||||
Sections above.
|
||||
|
||||
b) Give prominent notice with the combined library of the fact
|
||||
that part of it is a work based on the Library, and explaining
|
||||
where to find the accompanying uncombined form of the same work.
|
||||
|
||||
8. You may not copy, modify, sublicense, link with, or distribute
|
||||
the Library except as expressly provided under this License. Any
|
||||
attempt otherwise to copy, modify, sublicense, link with, or
|
||||
distribute the Library is void, and will automatically terminate your
|
||||
rights under this License. However, parties who have received copies,
|
||||
or rights, from you under this License will not have their licenses
|
||||
terminated so long as such parties remain in full compliance.
|
||||
|
||||
9. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Library or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Library (or any work based on the
|
||||
Library), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Library or works based on it.
|
||||
|
||||
10. Each time you redistribute the Library (or any work based on the
|
||||
Library), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute, link with or modify the Library
|
||||
subject to these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties with
|
||||
this License.
|
||||
|
||||
11. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Library at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Library by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Library.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under any
|
||||
particular circumstance, the balance of the section is intended to apply,
|
||||
and the section as a whole is intended to apply in other circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
12. If the distribution and/or use of the Library is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Library under this License may add
|
||||
an explicit geographical distribution limitation excluding those countries,
|
||||
so that distribution is permitted only in or among countries not thus
|
||||
excluded. In such case, this License incorporates the limitation as if
|
||||
written in the body of this License.
|
||||
|
||||
13. The Free Software Foundation may publish revised and/or new
|
||||
versions of the Lesser General Public License from time to time.
|
||||
Such new versions will be similar in spirit to the present version,
|
||||
but may differ in detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Library
|
||||
specifies a version number of this License which applies to it and
|
||||
"any later version", you have the option of following the terms and
|
||||
conditions either of that version or of any later version published by
|
||||
the Free Software Foundation. If the Library does not specify a
|
||||
license version number, you may choose any version ever published by
|
||||
the Free Software Foundation.
|
||||
|
||||
14. If you wish to incorporate parts of the Library into other free
|
||||
programs whose distribution conditions are incompatible with these,
|
||||
write to the author to ask for permission. For software which is
|
||||
copyrighted by the Free Software Foundation, write to the Free
|
||||
Software Foundation; we sometimes make exceptions for this. Our
|
||||
decision will be guided by the two goals of preserving the free status
|
||||
of all derivatives of our free software and of promoting the sharing
|
||||
and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
|
||||
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
|
||||
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
|
||||
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
|
||||
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
|
||||
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
|
||||
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
|
||||
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
|
||||
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
|
||||
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
|
||||
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
|
||||
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
|
||||
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
|
||||
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
|
||||
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
|
||||
DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Libraries
|
||||
|
||||
If you develop a new library, and you want it to be of the greatest
|
||||
possible use to the public, we recommend making it free software that
|
||||
everyone can redistribute and change. You can do so by permitting
|
||||
redistribution under these terms (or, alternatively, under the terms of the
|
||||
ordinary General Public License).
|
||||
|
||||
To apply these terms, attach the following notices to the library. It is
|
||||
safest to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least the
|
||||
"copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the library's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This library is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU Lesser General Public
|
||||
License as published by the Free Software Foundation; either
|
||||
version 2.1 of the License, or (at your option) any later version.
|
||||
|
||||
This library is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
Lesser General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU Lesser General Public
|
||||
License along with this library; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a "copyright disclaimer" for the library, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the
|
||||
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
|
||||
|
||||
<signature of Ty Coon>, 1 April 1990
|
||||
Ty Coon, President of Vice
|
||||
|
||||
That's all there is to it!
|
||||
292
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/rst2html.css
vendored
Normal file
292
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/rst2html.css
vendored
Normal file
@@ -0,0 +1,292 @@
|
||||
/*
|
||||
:Author: David Goodger
|
||||
:Contact: goodger@users.sourceforge.net
|
||||
:Date: $Date: 2007-04-11 11:48:16 +0100 (Wed, 11 Apr 2007) $
|
||||
:Revision: $Revision: 2791 $
|
||||
:Copyright: This stylesheet has been placed in the public domain.
|
||||
:Modified by: Kate Ward <kate.ward@forestent.com>
|
||||
|
||||
Default cascading style sheet for the HTML output of Docutils.
|
||||
|
||||
See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
|
||||
customize this style sheet.
|
||||
*/
|
||||
|
||||
/* used to remove borders from tables and images */
|
||||
.borderless, table.borderless td, table.borderless th {
|
||||
border: 0 }
|
||||
|
||||
table.borderless td, table.borderless th {
|
||||
/* Override padding for "table.docutils td" with "! important".
|
||||
The right padding separates the table cells. */
|
||||
padding: 0 0.5em 0 0 ! important }
|
||||
|
||||
.first {
|
||||
/* Override more specific margin styles with "! important". */
|
||||
margin-top: 0 ! important }
|
||||
|
||||
.last, .with-subtitle {
|
||||
margin-bottom: 0 ! important }
|
||||
|
||||
.hidden {
|
||||
display: none }
|
||||
|
||||
a.toc-backref {
|
||||
text-decoration: none ;
|
||||
color: black }
|
||||
|
||||
blockquote.epigraph {
|
||||
margin: 2em 5em ; }
|
||||
|
||||
dl.docutils dd {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
/* Uncomment (and remove this text!) to get bold-faced definition list terms
|
||||
dl.docutils dt {
|
||||
font-weight: bold }
|
||||
*/
|
||||
|
||||
div.abstract {
|
||||
margin: 2em 5em }
|
||||
|
||||
div.abstract p.topic-title {
|
||||
font-weight: bold ;
|
||||
text-align: center }
|
||||
|
||||
div.admonition, div.attention, div.caution, div.danger, div.error,
|
||||
div.hint, div.important, div.note, div.tip, div.warning {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.admonition p.admonition-title, div.hint p.admonition-title,
|
||||
div.important p.admonition-title, div.note p.admonition-title,
|
||||
div.tip p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
/* Uncomment (and remove this text!) to get reduced vertical space in
|
||||
compound paragraphs.
|
||||
div.compound .compound-first, div.compound .compound-middle {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
div.compound .compound-last, div.compound .compound-middle {
|
||||
margin-top: 0.5em }
|
||||
*/
|
||||
|
||||
div.dedication {
|
||||
margin: 2em 5em ;
|
||||
text-align: center ;
|
||||
font-style: italic }
|
||||
|
||||
div.dedication p.topic-title {
|
||||
font-weight: bold ;
|
||||
font-style: normal }
|
||||
|
||||
div.figure {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
div.footer, div.header {
|
||||
clear: both;
|
||||
font-size: smaller }
|
||||
|
||||
div.line-block {
|
||||
display: block ;
|
||||
margin-top: 1em ;
|
||||
margin-bottom: 1em }
|
||||
|
||||
div.line-block div.line-block {
|
||||
margin-top: 0 ;
|
||||
margin-bottom: 0 ;
|
||||
margin-left: 1.5em }
|
||||
|
||||
div.sidebar {
|
||||
margin-left: 1em ;
|
||||
border: medium outset ;
|
||||
padding: 1em ;
|
||||
background-color: #ffffee ;
|
||||
width: 40% ;
|
||||
float: right ;
|
||||
clear: right }
|
||||
|
||||
div.sidebar p.rubric {
|
||||
font-family: sans-serif ;
|
||||
font-size: medium }
|
||||
|
||||
div.system-messages {
|
||||
margin: 5em }
|
||||
|
||||
div.system-messages h1 {
|
||||
color: red }
|
||||
|
||||
div.system-message {
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.system-message p.system-message-title {
|
||||
color: red ;
|
||||
font-weight: bold }
|
||||
|
||||
div.topic {
|
||||
margin: 2em }
|
||||
|
||||
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
|
||||
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
|
||||
margin-top: 0.4em }
|
||||
|
||||
h1.title {
|
||||
text-align: center }
|
||||
|
||||
h2.subtitle {
|
||||
text-align: center }
|
||||
|
||||
hr.docutils {
|
||||
width: 75% }
|
||||
|
||||
img.align-left {
|
||||
clear: left }
|
||||
|
||||
img.align-right {
|
||||
clear: right }
|
||||
|
||||
ol.simple, ul.simple {
|
||||
margin-bottom: 1em }
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal }
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha }
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha }
|
||||
|
||||
ol.lowerroman {
|
||||
list-style: lower-roman }
|
||||
|
||||
ol.upperroman {
|
||||
list-style: upper-roman }
|
||||
|
||||
p.attribution {
|
||||
text-align: right ;
|
||||
margin-left: 50% }
|
||||
|
||||
p.caption {
|
||||
font-style: italic }
|
||||
|
||||
p.credits {
|
||||
font-style: italic ;
|
||||
font-size: smaller }
|
||||
|
||||
p.label {
|
||||
white-space: nowrap }
|
||||
|
||||
p.rubric {
|
||||
font-weight: bold ;
|
||||
font-size: larger ;
|
||||
color: maroon ;
|
||||
text-align: center }
|
||||
|
||||
p.sidebar-title {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold ;
|
||||
font-size: larger }
|
||||
|
||||
p.sidebar-subtitle {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
p.topic-title {
|
||||
font-weight: bold }
|
||||
|
||||
pre.address {
|
||||
margin-bottom: 0 ;
|
||||
margin-top: 0 ;
|
||||
font-family: serif ;
|
||||
font-size: 100% }
|
||||
|
||||
pre.literal-block, pre.doctest-block {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em ;
|
||||
background-color: #eeeeee }
|
||||
|
||||
span.classifier {
|
||||
font-family: sans-serif ;
|
||||
font-style: oblique }
|
||||
|
||||
span.classifier-delimiter {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
span.interpreted {
|
||||
font-family: sans-serif }
|
||||
|
||||
span.option {
|
||||
white-space: nowrap }
|
||||
|
||||
span.pre {
|
||||
white-space: pre }
|
||||
|
||||
span.problematic {
|
||||
color: red }
|
||||
|
||||
span.section-subtitle {
|
||||
/* font-size relative to parent (h1..h6 element) */
|
||||
font-size: 80% }
|
||||
|
||||
table.citation {
|
||||
border-left: solid 1px gray;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docinfo {
|
||||
margin: 2em 4em }
|
||||
|
||||
/*
|
||||
table.docutils {
|
||||
margin-top: 0.5em ;
|
||||
margin-bottom: 0.5em }
|
||||
*/
|
||||
|
||||
table.footnote {
|
||||
border-left: solid 1px black;
|
||||
margin-left: 1px ;
|
||||
font-size: 80% }
|
||||
}
|
||||
|
||||
table.docutils td, table.docutils th,
|
||||
table.docinfo td, table.docinfo th {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
vertical-align: top }
|
||||
|
||||
table.docutils th.field-name, table.docinfo th.docinfo-name {
|
||||
font-weight: bold ;
|
||||
text-align: left ;
|
||||
white-space: nowrap ;
|
||||
padding-left: 0 }
|
||||
|
||||
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
|
||||
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
|
||||
font-size: 100% }
|
||||
|
||||
/*
|
||||
tt.docutils {
|
||||
background-color: #eeeeee }
|
||||
*/
|
||||
|
||||
ul.auto-toc {
|
||||
list-style-type: none }
|
||||
|
||||
/* customizations by kward */
|
||||
|
||||
h1 { font-size: 133%; border-top:1px solid #CCCCFF; }
|
||||
h1.title { font-size: 150%; border-top:0px; padding-top: 1em; }
|
||||
/* div.document { font-size: 90% } */
|
||||
880
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/shunit2.html
vendored
Normal file
880
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/shunit2.html
vendored
Normal file
@@ -0,0 +1,880 @@
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
|
||||
<title>shUnit2 2.1.x Documentation</title>
|
||||
<style type="text/css">
|
||||
|
||||
/*
|
||||
:Author: David Goodger
|
||||
:Contact: goodger@users.sourceforge.net
|
||||
:Date: $Date: 2007-04-11 11:48:16 +0100 (Wed, 11 Apr 2007) $
|
||||
:Revision: $Revision: 2791 $
|
||||
:Copyright: This stylesheet has been placed in the public domain.
|
||||
:Modified by: Kate Ward <kate.ward@forestent.com>
|
||||
|
||||
Default cascading style sheet for the HTML output of Docutils.
|
||||
|
||||
See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
|
||||
customize this style sheet.
|
||||
*/
|
||||
|
||||
/* used to remove borders from tables and images */
|
||||
.borderless, table.borderless td, table.borderless th {
|
||||
border: 0 }
|
||||
|
||||
table.borderless td, table.borderless th {
|
||||
/* Override padding for "table.docutils td" with "! important".
|
||||
The right padding separates the table cells. */
|
||||
padding: 0 0.5em 0 0 ! important }
|
||||
|
||||
.first {
|
||||
/* Override more specific margin styles with "! important". */
|
||||
margin-top: 0 ! important }
|
||||
|
||||
.last, .with-subtitle {
|
||||
margin-bottom: 0 ! important }
|
||||
|
||||
.hidden {
|
||||
display: none }
|
||||
|
||||
a.toc-backref {
|
||||
text-decoration: none ;
|
||||
color: black }
|
||||
|
||||
blockquote.epigraph {
|
||||
margin: 2em 5em ; }
|
||||
|
||||
dl.docutils dd {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
/* Uncomment (and remove this text!) to get bold-faced definition list terms
|
||||
dl.docutils dt {
|
||||
font-weight: bold }
|
||||
*/
|
||||
|
||||
div.abstract {
|
||||
margin: 2em 5em }
|
||||
|
||||
div.abstract p.topic-title {
|
||||
font-weight: bold ;
|
||||
text-align: center }
|
||||
|
||||
div.admonition, div.attention, div.caution, div.danger, div.error,
|
||||
div.hint, div.important, div.note, div.tip, div.warning {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.admonition p.admonition-title, div.hint p.admonition-title,
|
||||
div.important p.admonition-title, div.note p.admonition-title,
|
||||
div.tip p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
/* Uncomment (and remove this text!) to get reduced vertical space in
|
||||
compound paragraphs.
|
||||
div.compound .compound-first, div.compound .compound-middle {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
div.compound .compound-last, div.compound .compound-middle {
|
||||
margin-top: 0.5em }
|
||||
*/
|
||||
|
||||
div.dedication {
|
||||
margin: 2em 5em ;
|
||||
text-align: center ;
|
||||
font-style: italic }
|
||||
|
||||
div.dedication p.topic-title {
|
||||
font-weight: bold ;
|
||||
font-style: normal }
|
||||
|
||||
div.figure {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
div.footer, div.header {
|
||||
clear: both;
|
||||
font-size: smaller }
|
||||
|
||||
div.line-block {
|
||||
display: block ;
|
||||
margin-top: 1em ;
|
||||
margin-bottom: 1em }
|
||||
|
||||
div.line-block div.line-block {
|
||||
margin-top: 0 ;
|
||||
margin-bottom: 0 ;
|
||||
margin-left: 1.5em }
|
||||
|
||||
div.sidebar {
|
||||
margin-left: 1em ;
|
||||
border: medium outset ;
|
||||
padding: 1em ;
|
||||
background-color: #ffffee ;
|
||||
width: 40% ;
|
||||
float: right ;
|
||||
clear: right }
|
||||
|
||||
div.sidebar p.rubric {
|
||||
font-family: sans-serif ;
|
||||
font-size: medium }
|
||||
|
||||
div.system-messages {
|
||||
margin: 5em }
|
||||
|
||||
div.system-messages h1 {
|
||||
color: red }
|
||||
|
||||
div.system-message {
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.system-message p.system-message-title {
|
||||
color: red ;
|
||||
font-weight: bold }
|
||||
|
||||
div.topic {
|
||||
margin: 2em }
|
||||
|
||||
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
|
||||
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
|
||||
margin-top: 0.4em }
|
||||
|
||||
h1.title {
|
||||
text-align: center }
|
||||
|
||||
h2.subtitle {
|
||||
text-align: center }
|
||||
|
||||
hr.docutils {
|
||||
width: 75% }
|
||||
|
||||
img.align-left {
|
||||
clear: left }
|
||||
|
||||
img.align-right {
|
||||
clear: right }
|
||||
|
||||
ol.simple, ul.simple {
|
||||
margin-bottom: 1em }
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal }
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha }
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha }
|
||||
|
||||
ol.lowerroman {
|
||||
list-style: lower-roman }
|
||||
|
||||
ol.upperroman {
|
||||
list-style: upper-roman }
|
||||
|
||||
p.attribution {
|
||||
text-align: right ;
|
||||
margin-left: 50% }
|
||||
|
||||
p.caption {
|
||||
font-style: italic }
|
||||
|
||||
p.credits {
|
||||
font-style: italic ;
|
||||
font-size: smaller }
|
||||
|
||||
p.label {
|
||||
white-space: nowrap }
|
||||
|
||||
p.rubric {
|
||||
font-weight: bold ;
|
||||
font-size: larger ;
|
||||
color: maroon ;
|
||||
text-align: center }
|
||||
|
||||
p.sidebar-title {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold ;
|
||||
font-size: larger }
|
||||
|
||||
p.sidebar-subtitle {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
p.topic-title {
|
||||
font-weight: bold }
|
||||
|
||||
pre.address {
|
||||
margin-bottom: 0 ;
|
||||
margin-top: 0 ;
|
||||
font-family: serif ;
|
||||
font-size: 100% }
|
||||
|
||||
pre.literal-block, pre.doctest-block {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em ;
|
||||
background-color: #eeeeee }
|
||||
|
||||
span.classifier {
|
||||
font-family: sans-serif ;
|
||||
font-style: oblique }
|
||||
|
||||
span.classifier-delimiter {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
span.interpreted {
|
||||
font-family: sans-serif }
|
||||
|
||||
span.option {
|
||||
white-space: nowrap }
|
||||
|
||||
span.pre {
|
||||
white-space: pre }
|
||||
|
||||
span.problematic {
|
||||
color: red }
|
||||
|
||||
span.section-subtitle {
|
||||
/* font-size relative to parent (h1..h6 element) */
|
||||
font-size: 80% }
|
||||
|
||||
table.citation {
|
||||
border-left: solid 1px gray;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docinfo {
|
||||
margin: 2em 4em }
|
||||
|
||||
/*
|
||||
table.docutils {
|
||||
margin-top: 0.5em ;
|
||||
margin-bottom: 0.5em }
|
||||
*/
|
||||
|
||||
table.footnote {
|
||||
border-left: solid 1px black;
|
||||
margin-left: 1px ;
|
||||
font-size: 80% }
|
||||
}
|
||||
|
||||
table.docutils td, table.docutils th,
|
||||
table.docinfo td, table.docinfo th {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
vertical-align: top }
|
||||
|
||||
table.docutils th.field-name, table.docinfo th.docinfo-name {
|
||||
font-weight: bold ;
|
||||
text-align: left ;
|
||||
white-space: nowrap ;
|
||||
padding-left: 0 }
|
||||
|
||||
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
|
||||
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
|
||||
font-size: 100% }
|
||||
|
||||
/*
|
||||
tt.docutils {
|
||||
background-color: #eeeeee }
|
||||
*/
|
||||
|
||||
ul.auto-toc {
|
||||
list-style-type: none }
|
||||
|
||||
/* customizations by kward */
|
||||
|
||||
h1 { font-size: 133%; border-top:1px solid #CCCCFF; }
|
||||
h1.title { font-size: 150%; border-top:0px; padding-top: 1em; }
|
||||
/* div.document { font-size: 90% } */
|
||||
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="document" id="shunit2-2-1-x-documentation">
|
||||
<h1 class="title">shUnit2 2.1.x Documentation</h1>
|
||||
|
||||
<div class="section" id="abstract">
|
||||
<h1><a class="toc-backref" href="#id1">Abstract</a></h1>
|
||||
<p><a class="reference external" href="http://shunit2.googlecode.com/">shUnit2</a> is a <a class="reference external" href="http://en.wikipedia.org/wiki/XUnit">xUnit</a> unit test framework for Bourne based shell scripts, and it
|
||||
is designed to work in a similar manner to <a class="reference external" href="http://www.junit.org/">JUnit</a>, <a class="reference external" href="http://pyunit.sourceforge.net/">PyUnit</a>, etc.. If you have
|
||||
ever had the desire to write a unit test for a shell script, shUnit2 can do the
|
||||
job.</p>
|
||||
<div class="contents topic" id="table-of-contents">
|
||||
<p class="topic-title first">Table of Contents</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="#abstract" id="id1">Abstract</a></li>
|
||||
<li><a class="reference internal" href="#introduction" id="id2">Introduction</a><ul>
|
||||
<li><a class="reference internal" href="#credits-contributors" id="id3">Credits / Contributors</a></li>
|
||||
<li><a class="reference internal" href="#feedback" id="id4">Feedback</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#quickstart" id="id5">Quickstart</a></li>
|
||||
<li><a class="reference internal" href="#function-reference" id="id6">Function Reference</a><ul>
|
||||
<li><a class="reference internal" href="#general-info" id="id7">General Info</a></li>
|
||||
<li><a class="reference internal" href="#asserts" id="id8">Asserts</a></li>
|
||||
<li><a class="reference internal" href="#failures" id="id9">Failures</a></li>
|
||||
<li><a class="reference internal" href="#setup-teardown" id="id10">Setup/Teardown</a></li>
|
||||
<li><a class="reference internal" href="#skipping" id="id11">Skipping</a></li>
|
||||
<li><a class="reference internal" href="#suites" id="id12">Suites</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#advanced-usage" id="id13">Advanced Usage</a><ul>
|
||||
<li><a class="reference internal" href="#some-constants-you-can-use" id="id14">Some constants you can use</a></li>
|
||||
<li><a class="reference internal" href="#error-handling" id="id15">Error handling</a></li>
|
||||
<li><a class="reference internal" href="#including-line-numbers-in-asserts-macros" id="id16">Including Line Numbers in Asserts (Macros)</a></li>
|
||||
<li><a class="reference internal" href="#test-skipping" id="id17">Test Skipping</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#appendix" id="id18">Appendix</a><ul>
|
||||
<li><a class="reference internal" href="#getting-help" id="id19">Getting help</a></li>
|
||||
<li><a class="reference internal" href="#zsh" id="id20">Zsh</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="introduction">
|
||||
<h1><a class="toc-backref" href="#id2">Introduction</a></h1>
|
||||
<p>shUnit2 was originally developed to provide a consistent testing solution for
|
||||
<a class="reference external" href="http://log4sh.sourceforge.net/">log4sh</a>, a shell based logging framework similar to <a class="reference external" href="http://logging.apache.org/">log4j</a>. During the
|
||||
development of that product, a repeated problem of having things work just fine
|
||||
under one shell (<tt class="docutils literal">/bin/bash</tt> on Linux to be specific), and then not working
|
||||
under another shell (<tt class="docutils literal">/bin/sh</tt> on Solaris) kept coming up. Although several
|
||||
simple tests were run, they were not adequate and did not catch some corner
|
||||
cases. The decision was finally made to write a proper unit test framework after
|
||||
multiple brown-bag releases were made. <em>Research was done to look for an
|
||||
existing product that met the testing requirements, but no adequate product was
|
||||
found.</em></p>
|
||||
<p>Tested Operating Systems (varies over time)</p>
|
||||
<ul class="simple">
|
||||
<li>Cygwin</li>
|
||||
<li>FreeBSD (user supported)</li>
|
||||
<li>Linux (Gentoo, Ubuntu)</li>
|
||||
<li>Mac OS X</li>
|
||||
<li>Solaris 8, 9, 10 (inc. OpenSolaris)</li>
|
||||
</ul>
|
||||
<p>Tested Shells</p>
|
||||
<ul class="simple">
|
||||
<li>Bourne Shell (<strong>sh</strong>)</li>
|
||||
<li>BASH - GNU Bourne Again SHell (<strong>bash</strong>)</li>
|
||||
<li>DASH (<strong>dash</strong>)</li>
|
||||
<li>Korn Shell (<strong>ksh</strong>)</li>
|
||||
<li>pdksh - Public Domain Korn Shell (<strong>pdksh</strong>)</li>
|
||||
<li>zsh - Zsh (<strong>zsh</strong>) (since 2.1.2) <em>please see the Zsh shell errata for more
|
||||
information</em></li>
|
||||
</ul>
|
||||
<p>See the appropriate Release Notes for this release
|
||||
(<tt class="docutils literal"><span class="pre">doc/RELEASE_NOTES-X.X.X.txt</span></tt>) for the list of actual versions tested.</p>
|
||||
<div class="section" id="credits-contributors">
|
||||
<h2><a class="toc-backref" href="#id3">Credits / Contributors</a></h2>
|
||||
<p>A list of contributors to shUnit2 can be found in the source archive in
|
||||
<tt class="docutils literal">doc/contributors.txt</tt>. Many thanks go out to all those who have contributed
|
||||
to make this a better tool.</p>
|
||||
<p>shUnit2 is the original product of many hours of work by Kate Ward, the primary
|
||||
author of the code. For other products by her, look up <a class="reference external" href="http://log4sh.sourceforge.net/">log4sh</a> or <a class="reference external" href="http://shflags.googlecode.com/">shFlags</a>, or
|
||||
visit her website at <a class="reference external" href="http://forestent.com/">http://forestent.com/</a>.</p>
|
||||
</div>
|
||||
<div class="section" id="feedback">
|
||||
<h2><a class="toc-backref" href="#id4">Feedback</a></h2>
|
||||
<p>Feedback is most certainly welcome for this document. Send your additions,
|
||||
comments and criticisms to the <a class="reference external" href="mailto:shunit2-users@google.com">shunit2-users@google.com</a> mailing list.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="quickstart">
|
||||
<h1><a class="toc-backref" href="#id5">Quickstart</a></h1>
|
||||
<p>This section will give a very quick start to running unit tests with shUnit2.
|
||||
More information is located in later sections.</p>
|
||||
<p>Here is a quick sample script to show how easy it is to write a unit test in
|
||||
shell. <em>Note: the script as it stands expects that you are running it from the
|
||||
``examples`` directory.</em></p>
|
||||
<pre class="literal-block">
|
||||
#! /bin/sh
|
||||
# file: examples/equality_test.sh
|
||||
|
||||
testEquality()
|
||||
{
|
||||
assertEquals 1 1
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/shunit2
|
||||
</pre>
|
||||
<p>Running the unit test should give results similar to the following.</p>
|
||||
<pre class="literal-block">
|
||||
testEquality
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK
|
||||
</pre>
|
||||
<p>W00t! 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 <tt class="docutils literal">shunit2</tt>
|
||||
library. The basic functionality for the script above goes like this:</p>
|
||||
<ul class="simple">
|
||||
<li>When shUnit2 is sourced, it will walk through any functions defined whose
|
||||
namestart with the string <tt class="docutils literal">test</tt> and add 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.</li>
|
||||
<li>Before any tests are executed, shUnit2 again looks for a function, this time
|
||||
one named <tt class="docutils literal">oneTimeSetUp()</tt>. 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 <tt class="docutils literal">oneTimeTearDown()</tt> function that does the same thing, but once all
|
||||
the tests have been completed. It is good for removing temporary directories,
|
||||
etc.</li>
|
||||
<li>shUnit2 is now ready to run tests. Before doing so though, it again looks for
|
||||
another function that might be declared, one named <tt class="docutils literal">setUp()</tt>. 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 <tt class="docutils literal">tearDown()</tt>. 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, <tt class="docutils literal">setUp()</tt> > <tt class="docutils literal">test()</tt> > <tt class="docutils literal">tearDown()</tt>, is
|
||||
repeated for all of the available tests.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
<p>We should now try adding a test that fails. Change your unit test to look like
|
||||
this.</p>
|
||||
<pre class="literal-block">
|
||||
#! /bin/sh
|
||||
# file: examples/party_test.sh
|
||||
|
||||
testEquality()
|
||||
{
|
||||
assertEquals 1 1
|
||||
}
|
||||
|
||||
testPartyLikeItIs1999()
|
||||
{
|
||||
year=`date '+%Y'`
|
||||
assertEquals "It's not 1999 :-(" \
|
||||
'1999' "${year}"
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/shunit2
|
||||
</pre>
|
||||
<p>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.</p>
|
||||
<p>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 <a class="reference external" href="http://log4sh.sourceforge.net/">log4sh</a> or <a class="reference external" href="http://shflags.googlecode.com/">shFlags</a>.
|
||||
Both provide excellent examples of more advanced usage. shUnit2 was after all
|
||||
written to help with the unit testing problems that <a class="reference external" href="http://log4sh.sourceforge.net/">log4sh</a> had.</p>
|
||||
</div>
|
||||
<div class="section" id="function-reference">
|
||||
<h1><a class="toc-backref" href="#id6">Function Reference</a></h1>
|
||||
<div class="section" id="general-info">
|
||||
<h2><a class="toc-backref" href="#id7">General Info</a></h2>
|
||||
<p>Any string values passed should be properly quoted -- they should must be
|
||||
surrounded by single-quote (') or double-quote (") characters -- so that the
|
||||
shell will properly parse them.</p>
|
||||
</div>
|
||||
<div class="section" id="asserts">
|
||||
<h2><a class="toc-backref" href="#id8">Asserts</a></h2>
|
||||
<dl class="docutils">
|
||||
<dt><tt class="docutils literal">assertEquals [message] expected actual</tt></dt>
|
||||
<dd>Asserts that <em>expected</em> and <em>actual</em> are equal to one another. The <em>expected</em>
|
||||
and <em>actual</em> values can be either strings or integer values as both will be
|
||||
treated as strings. The <em>message</em> is optional, and must be quoted.</dd>
|
||||
<dt><tt class="docutils literal">assertNotEquals [message] expected actual</tt></dt>
|
||||
<dd>Asserts that <em>unexpected</em> and <em>actual</em> are not equal to one another. The
|
||||
<em>unexpected</em> and <em>actual</em> values can be either strings or integer values as
|
||||
both will be treaded as strings. The <em>message</em> is optional, and must be
|
||||
quoted.</dd>
|
||||
<dt><tt class="docutils literal">assertSame [message] expected actual</tt></dt>
|
||||
<dd>This function is functionally equivalent to <tt class="docutils literal">assertEquals</tt>.</dd>
|
||||
<dt><tt class="docutils literal">assertNotSame [message] unexpected actual</tt></dt>
|
||||
<dd>This function is functionally equivalent to <tt class="docutils literal">assertNotEquals</tt>.</dd>
|
||||
<dt><tt class="docutils literal">assertNull [message] value</tt></dt>
|
||||
<dd>Asserts that <em>value</em> is <em>null</em>, or in shell terms, a zero-length string. The
|
||||
<em>value</em> must be a string as an integer value does not translate into a
|
||||
zero-length string. The <em>message</em> is optional, and must be quoted.</dd>
|
||||
<dt><tt class="docutils literal">assertNotNull [message] value</tt></dt>
|
||||
<dd>Asserts that <em>value</em> is <em>not null</em>, or in shell terms, a non-empty string. The
|
||||
<em>value</em> may be a string or an integer as the later will be parsed as a
|
||||
non-empty string value. The <em>message</em> is optional, and must be quoted.</dd>
|
||||
<dt><tt class="docutils literal">assertTrue [message] condition</tt></dt>
|
||||
<dd><p class="first">Asserts that a given shell test <em>condition</em> is <em>true</em>. The condition can be as
|
||||
simple as a shell <em>true</em> value (the value <tt class="docutils literal">0</tt> -- equivalent to
|
||||
<tt class="docutils literal">${SHUNIT_TRUE}</tt>), or a more sophisticated shell conditional expression. The
|
||||
<em>message</em> is optional, and must be quoted.</p>
|
||||
<p>A sophisticated shell conditional expression is equivalent to what the <strong>if</strong>
|
||||
or <strong>while</strong> shell built-ins would use (more specifically, what the <strong>test</strong>
|
||||
command would use). Testing for example whether some value is greater than
|
||||
another value can be done this way.</p>
|
||||
<pre class="literal-block">
|
||||
assertTrue "[ 34 -gt 23 ]"
|
||||
</pre>
|
||||
<p>Testing for the ability to read a file can also be done. This particular test
|
||||
will fail.</p>
|
||||
<pre class="literal-block">
|
||||
assertTrue 'test failed' "[ -r /some/non-existant/file' ]"
|
||||
</pre>
|
||||
<p>As the expressions are standard shell <strong>test</strong> expressions, it is possible to
|
||||
string multiple expressions together with <tt class="docutils literal"><span class="pre">-a</span></tt> and <tt class="docutils literal"><span class="pre">-o</span></tt> in the standard
|
||||
fashion. This test will succeed as the entire expression evaluates to <em>true</em>.</p>
|
||||
<pre class="literal-block">
|
||||
assertTrue 'test failed' '[ 1 -eq 1 -a 2 -eq 2 ]'
|
||||
</pre>
|
||||
<p class="last"><em>One word of warning: be very careful with your quoting as shell is not the
|
||||
most forgiving of bad quoting, and things will fail in strange ways.</em></p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">assertFalse [message] condition</tt></dt>
|
||||
<dd><p class="first">Asserts that a given shell test <em>condition</em> is <em>false</em>. The condition can be
|
||||
as simple as a shell <em>false</em> value (the value <tt class="docutils literal">1</tt> -- equivalent to
|
||||
<tt class="docutils literal">${SHUNIT_FALSE}</tt>), or a more sophisticated shell conditional expression.
|
||||
The <em>message</em> is optional, and must be quoted.</p>
|
||||
<p class="last"><em>For examples of more sophisticated expressions, see ``assertTrue``.</em></p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" id="failures">
|
||||
<h2><a class="toc-backref" href="#id9">Failures</a></h2>
|
||||
<p>Just to clarify, failures <strong>do not</strong> test the various arguments against one
|
||||
another. Failures simply fail, optionally with a message, and that is all they
|
||||
do. If you need to test arguments against one another, use asserts.</p>
|
||||
<p>If all failures do is fail, why might one use them? There are times when you may
|
||||
have some very complicated logic that you need to test, and the simple asserts
|
||||
provided are simply not adequate. You can do your own validation of the code,
|
||||
use an <tt class="docutils literal">assertTrue ${SHUNIT_TRUE}</tt> if your own tests succeeded, and use a
|
||||
failure to record a failure.</p>
|
||||
<dl class="docutils">
|
||||
<dt><tt class="docutils literal">fail [message]</tt></dt>
|
||||
<dd>Fails the test immediately. The <em>message</em> is optional, and must be quoted.</dd>
|
||||
<dt><tt class="docutils literal">failNotEquals [message] unexpected actual</tt></dt>
|
||||
<dd><p class="first">Fails the test immediately, reporting that the <em>unexpected</em> and <em>actual</em>
|
||||
values are not equal to one another. The <em>message</em> is optional, and must be
|
||||
quoted.</p>
|
||||
<p class="last"><em>Note: no actual comparison of unexpected and actual is done.</em></p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">failSame [message] expected actual</tt></dt>
|
||||
<dd><p class="first">Fails the test immediately, reporting that the <em>expected</em> and <em>actual</em> values
|
||||
are the same. The <em>message</em> is optional, and must be quoted.</p>
|
||||
<p class="last"><em>Note: no actual comparison of expected and actual is done.</em></p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">failNotSame [message] expected actual</tt></dt>
|
||||
<dd><p class="first">Fails the test immediately, reporting that the <em>expected</em> and <em>actual</em> values
|
||||
are not the same. The <em>message</em> is optional, and must be quoted.</p>
|
||||
<p class="last"><em>Note: no actual comparison of expected and actual is done.</em></p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" id="setup-teardown">
|
||||
<h2><a class="toc-backref" href="#id10">Setup/Teardown</a></h2>
|
||||
<dl class="docutils">
|
||||
<dt><tt class="docutils literal">oneTimeSetUp</tt></dt>
|
||||
<dd><p class="first">This function can be be optionally overridden by the user in their test suite.</p>
|
||||
<p class="last">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.</p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">oneTimeTearDown</tt></dt>
|
||||
<dd><p class="first">This function can be be optionally overridden by the user in their test suite.</p>
|
||||
<p class="last">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.</p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">setUp</tt></dt>
|
||||
<dd><p class="first">This function can be be optionally overridden by the user in their test suite.</p>
|
||||
<p class="last">If this function exists, it will be called before each test is run. It is
|
||||
useful to reset the environment before each test.</p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">tearDown</tt></dt>
|
||||
<dd><p class="first">This function can be be optionally overridden by the user in their test suite.</p>
|
||||
<p class="last">If this function exists, it will be called after each test completes. It is
|
||||
useful to clean up the environment after each test.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" id="skipping">
|
||||
<h2><a class="toc-backref" href="#id11">Skipping</a></h2>
|
||||
<dl class="docutils">
|
||||
<dt><tt class="docutils literal">startSkipping</tt></dt>
|
||||
<dd>This function forces the remaining <em>assert</em> and <em>fail</em> functions to be
|
||||
"skipped", i.e. they will have no effect. Each function skipped will be
|
||||
recorded so that the total of asserts and fails will not be altered.</dd>
|
||||
<dt><tt class="docutils literal">endSkipping</tt></dt>
|
||||
<dd>This function returns calls to the <em>assert</em> and <em>fail</em> functions to their
|
||||
default behavior, i.e. they will be called.</dd>
|
||||
<dt><tt class="docutils literal">isSkipping</tt></dt>
|
||||
<dd>This function returns the current state of skipping. It can be compared
|
||||
against <tt class="docutils literal">${SHUNIT_TRUE}</tt> or <tt class="docutils literal">${SHUNIT_FALSE}</tt> if desired.</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" id="suites">
|
||||
<h2><a class="toc-backref" href="#id12">Suites</a></h2>
|
||||
<p>The default behavior of shUnit2 is that all tests will be found dynamically. If
|
||||
you have a specific set of tests you want to run, or you don't want to use the
|
||||
standard naming scheme of prefixing your tests with <tt class="docutils literal">test</tt>, these functions
|
||||
are for you. Most users will never use them though.</p>
|
||||
<dl class="docutils">
|
||||
<dt><tt class="docutils literal">suite</tt></dt>
|
||||
<dd><p class="first">This function can be optionally overridden by the user in their test suite.</p>
|
||||
<p class="last">If this function exists, it will be called when <tt class="docutils literal">shunit2</tt> is sourced. If it
|
||||
does not exist, shUnit2 will search the parent script for all functions
|
||||
beginning with the word <tt class="docutils literal">test</tt>, and they will be added dynamically to the
|
||||
test suite.</p>
|
||||
</dd>
|
||||
<dt><tt class="docutils literal">suite_addTest name</tt></dt>
|
||||
<dd>This function adds a function named <em>name</em> to the list of tests scheduled for
|
||||
execution as part of this test suite. This function should only be called from
|
||||
within the <tt class="docutils literal">suite()</tt> function.</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="advanced-usage">
|
||||
<h1><a class="toc-backref" href="#id13">Advanced Usage</a></h1>
|
||||
<p>This section covers several advanced usage topics.</p>
|
||||
<div class="section" id="some-constants-you-can-use">
|
||||
<h2><a class="toc-backref" href="#id14">Some constants you can use</a></h2>
|
||||
<p>There are several constants provided by shUnit2 as variables that might be of
|
||||
use to you.</p>
|
||||
<p>Predefined</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="23%" />
|
||||
<col width="77%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td><tt class="docutils literal">SHUNIT_VERSION</tt></td>
|
||||
<td>The version of shUnit2 you are running.</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal">SHUNIT_TRUE</tt></td>
|
||||
<td>Standard shell <em>true</em> value (the integer value 0).</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal">SHUNIT_FALSE</tt></td>
|
||||
<td>Standard shell <em>false</em> value (the integer value 1).</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal">SHUNIT_ERROR</tt></td>
|
||||
<td>The integer value 2.</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal">SHUNIT_TMPDIR</tt></td>
|
||||
<td>Path to temporary directory that will be automatically
|
||||
cleaned up upon exit of shUnit2.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>User defined</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="23%" />
|
||||
<col width="77%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td><tt class="docutils literal">SHUNIT_PARENT</tt></td>
|
||||
<td>The filename of the shell script containing the tests. This
|
||||
is needed specifically for Zsh support.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="error-handling">
|
||||
<h2><a class="toc-backref" href="#id15">Error handling</a></h2>
|
||||
<p>The constants values <tt class="docutils literal">SHUNIT_TRUE</tt>, <tt class="docutils literal">SHUNIT_FALSE</tt>, and <tt class="docutils literal">SHUNIT_ERROR</tt> are
|
||||
returned from nearly every function to indicate the success or failure of the
|
||||
function. Additionally the variable <tt class="docutils literal">flags_error</tt> is filled with a detailed
|
||||
error message if any function returns with a <tt class="docutils literal">SHUNIT_ERROR</tt> value.</p>
|
||||
</div>
|
||||
<div class="section" id="including-line-numbers-in-asserts-macros">
|
||||
<h2><a class="toc-backref" href="#id16">Including Line Numbers in Asserts (Macros)</a></h2>
|
||||
<p>If you include lots of assert statements in an individual test function, it can
|
||||
become difficult to determine exactly which assert was thrown unless your
|
||||
messages are unique. To help somewhat, line numbers can be included in the
|
||||
assert messages. To enable this, a special shell "macro" must be used rather
|
||||
than the standard assert calls. <em>Shell doesn't actually have macros; the name is
|
||||
used here as the operation is similar to a standard macro.</em></p>
|
||||
<p>For example, to include line numbers for a <tt class="docutils literal">assertEquals()</tt> function call,
|
||||
replace the <tt class="docutils literal">assertEquals()</tt> with <tt class="docutils literal">${_ASSERT_EQUALS_}</tt>.</p>
|
||||
<p>Example -- Asserts with and without line numbers</p>
|
||||
<pre class="literal-block">
|
||||
#! /bin/sh
|
||||
# file: examples/lineno_test.sh
|
||||
|
||||
testLineNo()
|
||||
{
|
||||
# this assert will have line numbers included (e.g. "ASSERT:[123] ...")
|
||||
echo "ae: ${_ASSERT_EQUALS_}"
|
||||
${_ASSERT_EQUALS_} 'not equal' 1 2
|
||||
|
||||
# this assert will not have line numbers included (e.g. "ASSERT: ...")
|
||||
assertEquals 'not equal' 1 2
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/shunit2
|
||||
</pre>
|
||||
<p>Notes:</p>
|
||||
<ol class="arabic">
|
||||
<li><p class="first">Due to how shell parses command-line arguments, all strings used with macros
|
||||
should be quoted twice. Namely, single-quotes must be converted to
|
||||
single-double-quotes, and vice-versa. If the string being passed is
|
||||
absolutely for sure not empty, the extra quoting is not necessary.</p>
|
||||
<p>Normal <tt class="docutils literal">assertEquals</tt> call.</p>
|
||||
<pre class="literal-block">
|
||||
assertEquals 'some message' 'x' ''
|
||||
</pre>
|
||||
<p>Macro <tt class="docutils literal">_ASSERT_EQUALS_</tt> call. Note the extra quoting around the <em>message</em>
|
||||
and the <em>null</em> value.</p>
|
||||
<pre class="literal-block">
|
||||
_ASSERT_EQUALS_ '"some message"' 'x' '""'
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">Line numbers are not supported in all shells. If a shell does not support
|
||||
them, no errors will be thrown. Supported shells include: <strong>bash</strong> (>=3.0),
|
||||
<strong>ksh</strong>, <strong>pdksh</strong>, and <strong>zsh</strong>.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<div class="section" id="test-skipping">
|
||||
<h2><a class="toc-backref" href="#id17">Test Skipping</a></h2>
|
||||
<p>There are times where the test code you have written is just not applicable to
|
||||
the system you are running on. This section describes how to skip these tests
|
||||
but maintain the total test count.</p>
|
||||
<p>Probably the easiest example would be shell code that is meant to run under the
|
||||
<strong>bash</strong> shell, but the unit test is running under the Bourne shell. There are
|
||||
things that just won't work. The following test code demonstrates two sample
|
||||
functions, one that will be run under any shell, and the another that will run
|
||||
only under the <strong>bash</strong> shell.</p>
|
||||
<p>Example -- math include</p>
|
||||
<pre class="literal-block">
|
||||
# available as examples/math.inc
|
||||
|
||||
add_generic()
|
||||
{
|
||||
num_a=$1
|
||||
num_b=$2
|
||||
|
||||
expr $1 + $2
|
||||
}
|
||||
|
||||
add_bash()
|
||||
{
|
||||
num_a=$1
|
||||
num_b=$2
|
||||
|
||||
echo $(($1 + $2))
|
||||
}
|
||||
</pre>
|
||||
<p>And here is a corresponding unit test that correctly skips the <tt class="docutils literal">add_bash()</tt>
|
||||
function when the unit test is not running under the <strong>bash</strong> shell.</p>
|
||||
<p>Example -- math unit test</p>
|
||||
<pre class="literal-block">
|
||||
#! /bin/sh
|
||||
# available as examples/math_test.sh
|
||||
|
||||
testAdding()
|
||||
{
|
||||
result=`add_generic 1 2`
|
||||
assertEquals \
|
||||
"the result of '${result}' was wrong" \
|
||||
3 "${result}"
|
||||
|
||||
# disable non-generic tests
|
||||
[ -z "${BASH_VERSION:-}" ] && startSkipping
|
||||
|
||||
result=`add_bash 1 2`
|
||||
assertEquals \
|
||||
"the result of '${result}' was wrong" \
|
||||
3 "${result}"
|
||||
}
|
||||
|
||||
oneTimeSetUp()
|
||||
{
|
||||
# load include to test
|
||||
. ./math.inc
|
||||
}
|
||||
|
||||
# load and run shUnit2
|
||||
. ../src/shell/shunit2
|
||||
</pre>
|
||||
<p>Running the above test under the <strong>bash</strong> shell will result in the following
|
||||
output.</p>
|
||||
<pre class="literal-block">
|
||||
$ /bin/bash math_test.sh
|
||||
testAdding
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK
|
||||
</pre>
|
||||
<p>But, running the test under any other Unix shell will result in the following
|
||||
output.</p>
|
||||
<pre class="literal-block">
|
||||
$ /bin/ksh math_test.sh
|
||||
testAdding
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK (skipped=1)
|
||||
</pre>
|
||||
<p>As you can see, the total number of tests has not changed, but the report
|
||||
indicates that some tests were skipped.</p>
|
||||
<p>Skipping can be controlled with the following functions: <tt class="docutils literal">startSkipping()</tt>,
|
||||
<tt class="docutils literal">endSkipping()</tt>, and <tt class="docutils literal">isSkipping()</tt>. Once skipping is enabled, it will
|
||||
remain enabled until the end of the current test function call, after which
|
||||
skipping is disabled.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="appendix">
|
||||
<h1><a class="toc-backref" href="#id18">Appendix</a></h1>
|
||||
<div class="section" id="getting-help">
|
||||
<h2><a class="toc-backref" href="#id19">Getting help</a></h2>
|
||||
<p>For help, please send requests to either the <a class="reference external" href="mailto:shunit2-users@googlegroups.com">shunit2-users@googlegroups.com</a>
|
||||
mailing list (archives available on the web at
|
||||
<a class="reference external" href="http://groups.google.com/group/shunit2-users">http://groups.google.com/group/shunit2-users</a>) or directly to
|
||||
Kate Ward <kate dot ward at forestent dot com>.</p>
|
||||
</div>
|
||||
<div class="section" id="zsh">
|
||||
<h2><a class="toc-backref" href="#id20">Zsh</a></h2>
|
||||
<p>For compatibility with Zsh, there is one requirement that must be met -- the
|
||||
<tt class="docutils literal">shwordsplit</tt> option must be set. There are three ways to accomplish this.</p>
|
||||
<ol class="arabic">
|
||||
<li><p class="first">In the unit-test script, add the following shell code snippet before sourcing
|
||||
the <tt class="docutils literal">shunit2</tt> library.</p>
|
||||
<pre class="literal-block">
|
||||
setopt shwordsplit
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">When invoking <strong>zsh</strong> from either the command-line or as a script with
|
||||
<tt class="docutils literal">#!</tt>, add the <tt class="docutils literal"><span class="pre">-y</span></tt> parameter.</p>
|
||||
<pre class="literal-block">
|
||||
#! /bin/zsh -y
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">When invoking <strong>zsh</strong> from the command-line, add <tt class="docutils literal"><span class="pre">-o</span> shwordsplit <span class="pre">--</span></tt> as
|
||||
parameters before the script name.</p>
|
||||
<pre class="literal-block">
|
||||
$ zsh -o shwordsplit -- some_script
|
||||
</pre>
|
||||
</li>
|
||||
</ol>
|
||||
<!-- generate HTML using rst2html from Docutils of -->
|
||||
<!-- http://docutils.sourceforge.net/ -->
|
||||
<!-- -->
|
||||
<!-- vim:fileencoding=latin1:ft=rst:spell:sts=2:sw=2:tw=80 -->
|
||||
<!-- $Revision: 233 $ -->
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
562
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/shunit2.txt
vendored
Normal file
562
.zprezto/modules/prompt/external/powerlevel9k/shunit2/source/2.1/doc/shunit2.txt
vendored
Normal file
@@ -0,0 +1,562 @@
|
||||
===========================
|
||||
shUnit2 2.1.x Documentation
|
||||
===========================
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
shUnit2_ is a xUnit_ unit test framework for Bourne based shell scripts, and it
|
||||
is designed to work in a similar manner to JUnit_, PyUnit_, etc.. If you have
|
||||
ever had the desire to write a unit test for a shell script, shUnit2 can do the
|
||||
job.
|
||||
|
||||
.. contents:: Table of Contents
|
||||
:depth: 2
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
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, a repeated 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 several
|
||||
simple tests were run, they were not adequate and did not catch some corner
|
||||
cases. The decision was finally made to write a proper unit test framework after
|
||||
multiple brown-bag releases were made. *Research was done to look for an
|
||||
existing product that met the testing requirements, but no adequate product was
|
||||
found.*
|
||||
|
||||
Tested Operating Systems (varies over time)
|
||||
|
||||
- Cygwin
|
||||
- FreeBSD (user supported)
|
||||
- Linux (Gentoo, Ubuntu)
|
||||
- Mac OS X
|
||||
- Solaris 8, 9, 10 (inc. OpenSolaris)
|
||||
|
||||
Tested Shells
|
||||
|
||||
- Bourne Shell (**sh**)
|
||||
- BASH - GNU Bourne Again SHell (**bash**)
|
||||
- DASH (**dash**)
|
||||
- Korn Shell (**ksh**)
|
||||
- pdksh - Public Domain Korn Shell (**pdksh**)
|
||||
- zsh - Zsh (**zsh**) (since 2.1.2) *please see the Zsh shell errata for more
|
||||
information*
|
||||
|
||||
See the appropriate Release Notes for this release
|
||||
(``doc/RELEASE_NOTES-X.X.X.txt``) for the list of actual versions tested.
|
||||
|
||||
Credits / Contributors
|
||||
----------------------
|
||||
|
||||
A list of contributors to shUnit2 can be found in the source archive in
|
||||
``doc/contributors.txt``. Many thanks go out to all those who have contributed
|
||||
to make this a better tool.
|
||||
|
||||
shUnit2 is the original product of many hours of work by Kate Ward, the primary
|
||||
author of the code. For other products by her, look up log4sh_ or shFlags_, or
|
||||
visit her website at http://forestent.com/.
|
||||
|
||||
Feedback
|
||||
--------
|
||||
|
||||
Feedback is most certainly welcome for this document. Send your additions,
|
||||
comments and criticisms to the shunit2-users@google.com mailing list.
|
||||
|
||||
Quickstart
|
||||
==========
|
||||
|
||||
This section will give a very quick start to running unit tests with shUnit2.
|
||||
More information is located in later sections.
|
||||
|
||||
Here is a quick sample script to show how easy it is to write a unit test in
|
||||
shell. *Note: the script as it stands expects that you are running it from the
|
||||
``examples`` directory.* ::
|
||||
|
||||
#! /bin/sh
|
||||
# file: examples/equality_test.sh
|
||||
|
||||
testEquality()
|
||||
{
|
||||
assertEquals 1 1
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/shunit2
|
||||
|
||||
Running the unit test should give results similar to the following. ::
|
||||
|
||||
testEquality
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK
|
||||
|
||||
W00t! 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``
|
||||
library. The basic functionality for the script above goes like this:
|
||||
|
||||
- When shUnit2 is sourced, it will walk through any functions defined whose
|
||||
namestart with the string ``test`` and add 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
|
||||
# file: examples/party_test.sh
|
||||
|
||||
testEquality()
|
||||
{
|
||||
assertEquals 1 1
|
||||
}
|
||||
|
||||
testPartyLikeItIs1999()
|
||||
{
|
||||
year=`date '+%Y'`
|
||||
assertEquals "It's not 1999 :-(" \
|
||||
'1999' "${year}"
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/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_ or shFlags_.
|
||||
Both provide excellent examples of more advanced usage. shUnit2 was after all
|
||||
written to help with the unit testing problems that log4sh_ had.
|
||||
|
||||
Function Reference
|
||||
==================
|
||||
|
||||
General Info
|
||||
------------
|
||||
|
||||
Any string values passed should be properly quoted -- they should must be
|
||||
surrounded by single-quote (') or double-quote (") characters -- so that the
|
||||
shell will properly parse them.
|
||||
|
||||
Asserts
|
||||
-------
|
||||
|
||||
``assertEquals [message] expected actual``
|
||||
Asserts that *expected* and *actual* are equal to one another. The *expected*
|
||||
and *actual* values can be either strings or integer values as both will be
|
||||
treated as strings. The *message* is optional, and must be quoted.
|
||||
|
||||
``assertNotEquals [message] expected actual``
|
||||
Asserts that *unexpected* and *actual* are not equal to one another. The
|
||||
*unexpected* and *actual* values can be either strings or integer values as
|
||||
both will be treaded as strings. The *message* is optional, and must be
|
||||
quoted.
|
||||
|
||||
``assertSame [message] expected actual``
|
||||
This function is functionally equivalent to ``assertEquals``.
|
||||
|
||||
``assertNotSame [message] unexpected actual``
|
||||
This function is functionally equivalent to ``assertNotEquals``.
|
||||
|
||||
``assertNull [message] value``
|
||||
Asserts that *value* is *null*, or in shell terms, a zero-length string. The
|
||||
*value* must be a string as an integer value does not translate into a
|
||||
zero-length string. The *message* is optional, and must be quoted.
|
||||
|
||||
``assertNotNull [message] value``
|
||||
Asserts that *value* is *not null*, or in shell terms, a non-empty string. The
|
||||
*value* may be a string or an integer as the later will be parsed as a
|
||||
non-empty string value. The *message* is optional, and must be quoted.
|
||||
|
||||
``assertTrue [message] condition``
|
||||
Asserts that a given shell test *condition* is *true*. The condition can be as
|
||||
simple as a shell *true* value (the value ``0`` -- equivalent to
|
||||
``${SHUNIT_TRUE}``), or a more sophisticated shell conditional expression. The
|
||||
*message* is optional, and must be quoted.
|
||||
|
||||
A sophisticated shell conditional expression is equivalent to what the **if**
|
||||
or **while** shell built-ins would use (more specifically, what the **test**
|
||||
command would use). Testing for example whether some value is greater than
|
||||
another value can be done this way. ::
|
||||
|
||||
assertTrue "[ 34 -gt 23 ]"
|
||||
|
||||
Testing for the ability to read a file can also be done. This particular test
|
||||
will fail. ::
|
||||
|
||||
assertTrue 'test failed' "[ -r /some/non-existant/file' ]"
|
||||
|
||||
As the expressions are standard shell **test** expressions, it is possible to
|
||||
string multiple expressions together with ``-a`` and ``-o`` in the standard
|
||||
fashion. This test will succeed as the entire expression evaluates to *true*.
|
||||
::
|
||||
|
||||
assertTrue 'test failed' '[ 1 -eq 1 -a 2 -eq 2 ]'
|
||||
|
||||
*One word of warning: be very careful with your quoting as shell is not the
|
||||
most forgiving of bad quoting, and things will fail in strange ways.*
|
||||
|
||||
``assertFalse [message] condition``
|
||||
Asserts that a given shell test *condition* is *false*. The condition can be
|
||||
as simple as a shell *false* value (the value ``1`` -- equivalent to
|
||||
``${SHUNIT_FALSE}``), or a more sophisticated shell conditional expression.
|
||||
The *message* is optional, and must be quoted.
|
||||
|
||||
*For examples of more sophisticated expressions, see ``assertTrue``.*
|
||||
|
||||
Failures
|
||||
--------
|
||||
|
||||
Just to clarify, failures **do not** test the various arguments against one
|
||||
another. Failures simply fail, optionally with a message, and that is all they
|
||||
do. If you need to test arguments against one another, use asserts.
|
||||
|
||||
If all failures do is fail, why might one use them? There are times when you may
|
||||
have some very complicated logic that you need to test, and the simple asserts
|
||||
provided are simply not adequate. You can do your own validation of the code,
|
||||
use an ``assertTrue ${SHUNIT_TRUE}`` if your own tests succeeded, and use a
|
||||
failure to record a failure.
|
||||
|
||||
``fail [message]``
|
||||
Fails the test immediately. The *message* is optional, and must be quoted.
|
||||
|
||||
``failNotEquals [message] unexpected actual``
|
||||
Fails the test immediately, reporting that the *unexpected* and *actual*
|
||||
values are not equal to one another. The *message* is optional, and must be
|
||||
quoted.
|
||||
|
||||
*Note: no actual comparison of unexpected and actual is done.*
|
||||
|
||||
``failSame [message] expected actual``
|
||||
Fails the test immediately, reporting that the *expected* and *actual* values
|
||||
are the same. The *message* is optional, and must be quoted.
|
||||
|
||||
*Note: no actual comparison of expected and actual is done.*
|
||||
|
||||
``failNotSame [message] expected actual``
|
||||
Fails the test immediately, reporting that the *expected* and *actual* values
|
||||
are not the same. The *message* is optional, and must be quoted.
|
||||
|
||||
*Note: no actual comparison of expected and actual is done.*
|
||||
|
||||
Setup/Teardown
|
||||
--------------
|
||||
|
||||
``oneTimeSetUp``
|
||||
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.
|
||||
|
||||
``oneTimeTearDown``
|
||||
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.
|
||||
|
||||
``setUp``
|
||||
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.
|
||||
|
||||
``tearDown``
|
||||
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.
|
||||
|
||||
Skipping
|
||||
--------
|
||||
|
||||
``startSkipping``
|
||||
This function forces the remaining *assert* and *fail* functions to be
|
||||
"skipped", i.e. they will have no effect. Each function skipped will be
|
||||
recorded so that the total of asserts and fails will not be altered.
|
||||
|
||||
``endSkipping``
|
||||
This function returns calls to the *assert* and *fail* functions to their
|
||||
default behavior, i.e. they will be called.
|
||||
|
||||
``isSkipping``
|
||||
This function returns the current state of skipping. It can be compared
|
||||
against ``${SHUNIT_TRUE}`` or ``${SHUNIT_FALSE}`` if desired.
|
||||
|
||||
Suites
|
||||
------
|
||||
|
||||
The default behavior of shUnit2 is that all tests will be found dynamically. If
|
||||
you have a specific set of tests you want to run, or you don't want to use the
|
||||
standard naming scheme of prefixing your tests with ``test``, these functions
|
||||
are for you. Most users will never use them though.
|
||||
|
||||
``suite``
|
||||
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 ``test``, and they will be added dynamically to the
|
||||
test suite.
|
||||
|
||||
``suite_addTest name``
|
||||
This function adds a function named *name* to the list of tests scheduled for
|
||||
execution as part of this test suite. This function should only be called from
|
||||
within the ``suite()`` function.
|
||||
|
||||
Advanced Usage
|
||||
==============
|
||||
|
||||
This section covers several advanced usage topics.
|
||||
|
||||
Some constants you can use
|
||||
--------------------------
|
||||
|
||||
There are several constants provided by shUnit2 as variables that might be of
|
||||
use to you.
|
||||
|
||||
Predefined
|
||||
|
||||
================== ===========================================================
|
||||
``SHUNIT_VERSION`` The version of shUnit2 you are running.
|
||||
``SHUNIT_TRUE`` Standard shell *true* value (the integer value 0).
|
||||
``SHUNIT_FALSE`` Standard shell *false* value (the integer value 1).
|
||||
``SHUNIT_ERROR`` The integer value 2.
|
||||
``SHUNIT_TMPDIR`` Path to temporary directory that will be automatically
|
||||
cleaned up upon exit of shUnit2.
|
||||
================== ===========================================================
|
||||
|
||||
User defined
|
||||
|
||||
================== ===========================================================
|
||||
``SHUNIT_PARENT`` The filename of the shell script containing the tests. This
|
||||
is needed specifically for Zsh support.
|
||||
================== ===========================================================
|
||||
|
||||
Error handling
|
||||
--------------
|
||||
|
||||
The constants values ``SHUNIT_TRUE``, ``SHUNIT_FALSE``, and ``SHUNIT_ERROR`` are
|
||||
returned from nearly every function to indicate the success or failure of the
|
||||
function. Additionally the variable ``flags_error`` is filled with a detailed
|
||||
error message if any function returns with a ``SHUNIT_ERROR`` value.
|
||||
|
||||
Including Line Numbers in Asserts (Macros)
|
||||
------------------------------------------
|
||||
|
||||
If you include lots of assert statements in an individual test function, it can
|
||||
become difficult to determine exactly which assert was thrown unless your
|
||||
messages are unique. To help somewhat, line numbers can be included in the
|
||||
assert messages. To enable this, a special shell "macro" must be used rather
|
||||
than the standard assert calls. *Shell doesn't actually have macros; the name is
|
||||
used here as the operation is similar to a standard macro.*
|
||||
|
||||
For example, to include line numbers for a ``assertEquals()`` function call,
|
||||
replace the ``assertEquals()`` with ``${_ASSERT_EQUALS_}``.
|
||||
|
||||
Example<EFBFBD>--<2D>Asserts with and without line numbers ::
|
||||
|
||||
#! /bin/sh
|
||||
# file: examples/lineno_test.sh
|
||||
|
||||
testLineNo()
|
||||
{
|
||||
# this assert will have line numbers included (e.g. "ASSERT:[123] ...")
|
||||
echo "ae: ${_ASSERT_EQUALS_}"
|
||||
${_ASSERT_EQUALS_} 'not equal' 1 2
|
||||
|
||||
# this assert will not have line numbers included (e.g. "ASSERT: ...")
|
||||
assertEquals 'not equal' 1 2
|
||||
}
|
||||
|
||||
# load shunit2
|
||||
. ../src/shell/shunit2
|
||||
|
||||
Notes:
|
||||
|
||||
#. Due to how shell parses command-line arguments, all strings used with macros
|
||||
should be quoted twice. Namely, single-quotes must be converted to
|
||||
single-double-quotes, and vice-versa. If the string being passed is
|
||||
absolutely for sure not empty, the extra quoting is not necessary.
|
||||
|
||||
Normal ``assertEquals`` call. ::
|
||||
|
||||
assertEquals 'some message' 'x' ''
|
||||
|
||||
Macro ``_ASSERT_EQUALS_`` call. Note the extra quoting around the *message*
|
||||
and the *null* value. ::
|
||||
|
||||
_ASSERT_EQUALS_ '"some message"' 'x' '""'
|
||||
|
||||
#. Line numbers are not supported in all shells. If a shell does not support
|
||||
them, no errors will be thrown. Supported shells include: **bash** (>=3.0),
|
||||
**ksh**, **pdksh**, and **zsh**.
|
||||
|
||||
Test Skipping
|
||||
-------------
|
||||
|
||||
There are times where the test code you have written is just not applicable to
|
||||
the system you are running on. This section describes how to skip these tests
|
||||
but maintain the total test count.
|
||||
|
||||
Probably the easiest example would be shell code that is meant to run under the
|
||||
**bash** shell, but the unit test is running under the Bourne shell. There are
|
||||
things that just won't work. The following test code demonstrates two sample
|
||||
functions, one that will be run under any shell, and the another that will run
|
||||
only under the **bash** shell.
|
||||
|
||||
Example<EFBFBD>-- math include ::
|
||||
|
||||
# available as examples/math.inc
|
||||
|
||||
add_generic()
|
||||
{
|
||||
num_a=$1
|
||||
num_b=$2
|
||||
|
||||
expr $1 + $2
|
||||
}
|
||||
|
||||
add_bash()
|
||||
{
|
||||
num_a=$1
|
||||
num_b=$2
|
||||
|
||||
echo $(($1 + $2))
|
||||
}
|
||||
|
||||
And here is a corresponding unit test that correctly skips the ``add_bash()``
|
||||
function when the unit test is not running under the **bash** shell.
|
||||
|
||||
Example<EFBFBD>-- math unit test ::
|
||||
|
||||
#! /bin/sh
|
||||
# available as examples/math_test.sh
|
||||
|
||||
testAdding()
|
||||
{
|
||||
result=`add_generic 1 2`
|
||||
assertEquals \
|
||||
"the result of '${result}' was wrong" \
|
||||
3 "${result}"
|
||||
|
||||
# disable non-generic tests
|
||||
[ -z "${BASH_VERSION:-}" ] && startSkipping
|
||||
|
||||
result=`add_bash 1 2`
|
||||
assertEquals \
|
||||
"the result of '${result}' was wrong" \
|
||||
3 "${result}"
|
||||
}
|
||||
|
||||
oneTimeSetUp()
|
||||
{
|
||||
# load include to test
|
||||
. ./math.inc
|
||||
}
|
||||
|
||||
# load and run shUnit2
|
||||
. ../src/shell/shunit2
|
||||
|
||||
Running the above test under the **bash** shell will result in the following
|
||||
output. ::
|
||||
|
||||
$ /bin/bash math_test.sh
|
||||
testAdding
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK
|
||||
|
||||
But, running the test under any other Unix shell will result in the following
|
||||
output. ::
|
||||
|
||||
$ /bin/ksh math_test.sh
|
||||
testAdding
|
||||
|
||||
Ran 1 test.
|
||||
|
||||
OK (skipped=1)
|
||||
|
||||
As you can see, the total number of tests has not changed, but the report
|
||||
indicates that some tests were skipped.
|
||||
|
||||
Skipping can be controlled with the following functions: ``startSkipping()``,
|
||||
``endSkipping()``, and ``isSkipping()``. Once skipping is enabled, it will
|
||||
remain enabled until the end of the current test function call, after which
|
||||
skipping is disabled.
|
||||
|
||||
Appendix
|
||||
========
|
||||
|
||||
Getting help
|
||||
------------
|
||||
|
||||
For help, please send requests to either the shunit2-users@googlegroups.com
|
||||
mailing list (archives available on the web at
|
||||
http://groups.google.com/group/shunit2-users) or directly to
|
||||
Kate Ward <kate dot ward at forestent dot com>.
|
||||
|
||||
Zsh
|
||||
---
|
||||
|
||||
For compatibility with Zsh, there is one requirement that must be met -- the
|
||||
``shwordsplit`` option must be set. There are three ways to accomplish this.
|
||||
|
||||
#. In the unit-test script, add the following shell code snippet before sourcing
|
||||
the ``shunit2`` library. ::
|
||||
|
||||
setopt shwordsplit
|
||||
|
||||
#. When invoking **zsh** from either the command-line or as a script with
|
||||
``#!``, add the ``-y`` parameter. ::
|
||||
|
||||
#! /bin/zsh -y
|
||||
|
||||
#. When invoking **zsh** from the command-line, add ``-o shwordsplit --`` as
|
||||
parameters before the script name. ::
|
||||
|
||||
$ zsh -o shwordsplit -- some_script
|
||||
|
||||
.. _log4sh: http://log4sh.sourceforge.net/
|
||||
.. _log4j: http://logging.apache.org/
|
||||
.. _JUnit: http://www.junit.org/
|
||||
.. _PyUnit: http://pyunit.sourceforge.net/
|
||||
.. _shFlags: http://shflags.googlecode.com/
|
||||
.. _shUnit2: http://shunit2.googlecode.com/
|
||||
.. _xUnit: http://en.wikipedia.org/wiki/XUnit
|
||||
|
||||
.. generate HTML using rst2html from Docutils of
|
||||
.. http://docutils.sourceforge.net/
|
||||
..
|
||||
.. vim:fileencoding=latin1:ft=rst:spell:sts=2:sw=2:tw=80
|
||||
.. $Revision: 233 $
|
||||
Reference in New Issue
Block a user