svxf/dotfiles
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

update prezto

Browse Source
This commit is contained in:
svxf
2018-11-18 23:37:19 +04:00
parent a17ecf9f57
commit 2808949f26
352 changed files with 15169 additions and 25328 deletions
Download Patch File Download Diff File Expand all files Collapse all files

564
.zprezto/modules/prompt/external/powerlevel9k/shunit2/doc/shunit2.txt vendored Normal file
View File

@@ -0,0 +1,564 @@
===========================
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 ``doc/contributors.md``.
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-existent/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_COLOR`` Set this flag to control colored output support. Accepted
values are ``always``, ``auto`` (the default), and ``none``.
``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 $