source: vendor/current/lib/subunit/shell/README@ 740

Last change on this file since 740 was 740, checked in by Silvan Scherrer, 12 years ago

Samba Server: update vendor to 3.6.0

File size: 2.5 KB
Line 
1#
2# subunit shell bindings.
3# Copyright (C) 2006 Robert Collins <robertc@robertcollins.net>
4#
5# Licensed under either the Apache License, Version 2.0 or the BSD 3-clause
6# license at the users choice. A copy of both licenses are available in the
7# project source as Apache-2.0 and BSD. You may not use this file except in
8# compliance with one of these two licences.
9#
10# Unless required by applicable law or agreed to in writing, software
11# distributed under these licenses is distributed on an "AS IS" BASIS, WITHOUT
12# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
13# license you chose for the specific language governing permissions and
14# limitations under that license.
15#
16
17This tree contains shell bindings to the subunit protocol. They are written
18entirely in shell, and unit tested in shell. See the tests/ directory for the
19test scripts. You can use `make check` to run the tests. There is a trivial
20python test_shell.py which uses the pyunit gui to expose the test results in a
21compact form.
22
23The shell bindings consist of four functions which you can use to output test
24metadata trivially. See share/subunit.sh for the functions and comments.
25
26However, this is not a full test environment, its support code for reporting to
27subunit. You can look at ShUnit (http://shunit.sourceforge.net) for 'proper'
28shell based xUnit functionality. There is a patch for ShUnit 1.3
29(subunit-ui.patch) in the subunit source tree. I hope to have that integrated
30upstream in the near future. I will delete the copy of the patch in the subunit
31tree a release or two later.
32
33If you are a test environment maintainer - either homegrown, or ShUnit or some
34such, you will need to see how the subunit calls should be used. Here is what
35a manually written test using the bindings might look like:
36
37
38subunit_start_test "test name"
39# determine if test passes or fails
40result=$(something)
41if [ $result == 0 ]; then
42 subunit_pass_test "test name"
43else
44 subunit_fail_test "test name" <<END
45Something went wrong running something:
46exited with result: '$func_status'
47END
48fi
49
50Which when run with a subunit test runner will generate something like:
51test name ... ok
52
53on success, and:
54
55test name ... FAIL
56
57======================================================================
58FAIL: test name
59----------------------------------------------------------------------
60RemoteError:
61Something went wrong running something:
62exited with result: '1'
Note: See TracBrowser for help on using the repository browser.