[src/trunk]: src/external/bsd/atf/dist/atf-sh Add some information learned fr...

[kre <kre%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/8ef4a98e3342
branches:  trunk
changeset: 823933:8ef4a98e3342
user:      kre <kre%NetBSD.org@localhost>
date:      Mon May 15 04:54:09 2017 +0000

description:
Add some information learned from experience with using (and abusing)
this API...

While here do some markup improvements (it is amazing what one can
learn from observing a wizard at work!) (which still probably need more work.)
In particular, sh functions are not functions in the mdoc .Fn sense!
(Many places where explicit double quotes were not doing what was intended.)

diffstat:

 external/bsd/atf/dist/atf-sh/atf-sh-api.3 |  146 ++++++++++++++++++++---------
 1 files changed, 98 insertions(+), 48 deletions(-)

diffs (277 lines):

diff -r 740d881025c6 -r 8ef4a98e3342 external/bsd/atf/dist/atf-sh/atf-sh-api.3
--- a/external/bsd/atf/dist/atf-sh/atf-sh-api.3 Mon May 15 04:21:14 2017 +0000
+++ b/external/bsd/atf/dist/atf-sh/atf-sh-api.3 Mon May 15 04:54:09 2017 +0000
@@ -26,7 +26,7 @@
 .\" OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
 .\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd October 13, 2013
+.Dd May 15, 2017
 .Dt ATF-SH-API 3
 .Os
 .Sh NAME
@@ -51,25 +51,44 @@
 .Nm atf_test_case
 .Nd POSIX shell API to write ATF-based test programs
 .Sh SYNOPSIS
-.Fn atf_add_test_case "name"
-.Fn atf_check "command"
-.Fn atf_check_equal "expr1" "expr2"
-.Fn atf_config_get "var_name"
-.Fn atf_config_has "var_name"
-.Fn atf_expect_death "reason" "..."
-.Fn atf_expect_exit "exitcode" "reason" "..."
-.Fn atf_expect_fail "reason" "..."
-.Fn atf_expect_pass
-.Fn atf_expect_signal "signo" "reason" "..."
-.Fn atf_expect_timeout "reason" "..."
-.Fn atf_fail "reason"
-.Fn atf_get "var_name"
-.Fn atf_get_srcdir
-.Fn atf_pass
-.Fn atf_require_prog "prog_name"
-.Fn atf_set "var_name" "value"
-.Fn atf_skip "reason"
-.Fn atf_test_case "name" "cleanup"
+.Ic atf_add_test_case Dq name
+.br
+.Ic atf_check Dq command
+.br
+.Ic atf_check_equal Do expr1 Dc Dq expr2
+.br
+.Ic atf_config_get Dq var_name
+.br
+.Ic atf_config_has Dq var_name
+.br
+.Ic atf_expect_death Do reason Dc Dq \&...
+.br
+.Ic atf_expect_exit Do exitcode Dc Do reason Dc Dq \&...
+.br
+.Ic atf_expect_fail Do reason Dc Dq \&...
+.br
+.Ic atf_expect_pass
+.br
+.Ic atf_expect_signal Do signo Dc Do reason Dc Dq \&...
+.br
+.Ic atf_expect_timeout Do reason Dc Dq \&...
+.br
+.Ic atf_fail Dq reason
+.br
+.Ic atf_get Dq var_name
+.br
+.Ic atf_get_srcdir
+.br
+.Ic atf_pass
+.br
+.Ic atf_require_prog Dq prog_name
+.br
+.Ic atf_set Do var_name Dc Dq value
+.br
+.Ic atf_skip Dq reason
+.br
+.Ic atf_test_case Do name Dc Dq cleanup
+.br
 .Sh DESCRIPTION
 ATF
 provides a simple but powerful interface to easily write test programs in
@@ -114,13 +133,43 @@
     ... add additional test cases ...
 }
 .Ed
+.Pp
+All of these functions are required to return with an exit-status of
+zero, or ATF will determine that the test is faulty.
+In particular, this means that none may end with a conditional like:
+.Bd -literal -offset indent
+atf_sh_function() {
+    ... appropriate code here ...
+    condition-test && {
+       ... more code here ...
+    }
+}
+.Ed
+.Pp
+as if condition-test fails
+the return code from atf_sh_function will not be 0.
+This can be corrected by adding
+.Bd -literal -offset indent
+    return 0
+.Ed
+.Pp
+before the end of the function, or by writing it as
+.Bd -literal -offset indent
+atf_sh_function() {
+    ... appropriate code here ...
+    if condition-test
+    then
+       ... more code here ...
+    fi
+}
+.Ed
 .Ss Definition of test cases
 Test cases have an identifier and are composed of three different parts:
 the header, the body and an optional cleanup routine, all of which are
 described in
 .Xr atf-test-case 4 .
 To define test cases, one can use the
-.Fn atf_test_case
+.Ic atf_test_case
 function, which takes a first parameter specifiying the test case's
 name and instructs the library to set things up to accept it as a valid
 test case.
@@ -132,33 +181,34 @@
 .Em does not
 set the test case up for execution when the program is run.
 In order to do so, a later registration is needed through the
-.Fn atf_add_test_case
+.Ic atf_add_test_case
 function detailed in
 .Sx Program initialization .
 .Pp
 Later on, one must define the three parts of the body by providing two
 or three functions (remember that the cleanup routine is optional).
 These functions are named after the test case's identifier, and are
-.Fn <id>_head ,
-.Fn <id>_body
+.Ic <id>_head ,
+.Ic <id>_body
 and
-.Fn <id>_cleanup.
+.Ic <id>_cleanup.
 None of these take parameters when executed.
 .Ss Program initialization
 The test program must define an
-.Fn atf_init_test_cases
+.Ic atf_init_test_cases
 function, which is in charge of registering the test cases that will be
 executed at run time by using the
-.Fn atf_add_test_case
+.Ic atf_add_test_case
 function, which takes the name of a test case as its single parameter.
 This main function should not do anything else, except maybe sourcing
-auxiliary source files that define extra variables and functions.
+auxiliary source files that define extra variables and functions,
+or perhaps running simple tests to determine which test cases to add.
 .Ss Configuration variables
 The test case has read-only access to the current configuration variables
 through the
-.Fn atf_config_has
+.Ic atf_config_has
 and
-.Fn atf_config_get
+.Ic atf_config_get
 methods.
 The former takes a single parameter specifying a variable name and returns
 a boolean indicating whether the variable is defined or not.
@@ -170,17 +220,17 @@
 .Ss Access to the source directory
 It is possible to get the path to the test case's source directory from
 anywhere in the test program by using the
-.Fn atf_get_srcdir
+.Ic atf_get_srcdir
 function.
 It is interesting to note that this can be used inside
-.Fn atf_init_test_cases
+.Ic atf_init_test_cases
 to silently include additional helper files from the source directory.
 .Ss Requiring programs
 Aside from the
 .Va require.progs
 meta-data variable available in the header only, one can also check for
 additional programs in the test case's body by using the
-.Fn atf_require_prog
+.Ic atf_require_prog
 function, which takes the base name or full path of a single binary.
 Relative paths are forbidden.
 If it is not found, the test case will be automatically skipped.
@@ -189,10 +239,9 @@
 point the test is assumed to have
 .Em passed ,
 or at any explicit call to
-.Fn atf_pass ,
-.Fn atf_fail
-or
-.Fn atf_skip .
+.Ic atf_pass ,
+.Ic atf_fail
+.Ic atf_skip .
 These three functions terminate the execution of the test case immediately.
 The cleanup routine will be processed afterwards in a completely automated
 way, regardless of the test case's termination reason.
@@ -206,6 +255,7 @@
 was skipped, respectively.
 It is very important to provide a clear error message in both cases so that
 the user can quickly know why the test did not pass.
+This message must be a single line (no embedded newline characers.)
 .Ss Expectations
 Everything explained in the previous section changes when the test case
 expectations are redefined by the programmer.
@@ -215,20 +265,20 @@
 that describes what the test case expectations are at any point in time.
 The value of this property can change during execution by any of:
 .Bl -tag -width indent
-.It Fn atf_expect_death "reason" "..."
+.It Ic atf_expect_death Do reason Dc Dq \&...
 Expects the test case to exit prematurely regardless of the nature of the
 exit.
-.It Fn atf_expect_exit "exitcode" "reason" "..."
+.It Ic atf_expect_exit Do exitcode Dc Do reason Dc Dq \&...
 Expects the test case to exit cleanly.
 If
 .Va exitcode
 is not
-.Sq -1 ,
+.Sq \-1 ,
 .Xr atf-run 1
 will validate that the exit code of the test case matches the one provided
 in this call.
 Otherwise, the exact value will be ignored.
-.It Fn atf_expect_fail "reason"
+.It Ic atf_expect_fail Dq reason
 Any failure raised in this mode is recorded, but such failures do not report
 the test case as failed; instead, the test case finalizes cleanly and is
 reported as
@@ -245,28 +295,28 @@
 reporting a failure, signaling the developer that the test case must be
 adjusted to the new conditions.
 In this situation, it is useful, for example, to set
-.Fa reason
+.Va reason
 as the bug number for tracking purposes.
-.It Fn atf_expect_pass
+.It Ic atf_expect_pass
 This is the normal mode of execution.
 In this mode, any failure is reported as such to the user and the test case
 is marked as
 .Sq failed .
-.It Fn atf_expect_signal "signo" "reason" "..."
+.It Ic atf_expect_signal Do signo Dc Do reason Dc Dq \&...
 Expects the test case to terminate due to the reception of a signal.
 If
 .Va signo
 is not
-.Sq -1 ,
+.Sq \-1 ,
 .Xr atf-run 1
 will validate that the signal that terminated the test case matches the one
 provided in this call.
 Otherwise, the exact value will be ignored.
-.It Fn atf_expect_timeout "reason" "..."
+.It Ic atf_expect_timeout Do reason Dc Dq \&...
 Expects the test case to execute for longer than its timeout.
 .El
 .Ss Helper functions for common checks
-.Fn atf_check [options] command [args]
+.Ic atf_check Oo options Oc command Op args
 .Pp
 This function wraps the execution of the
 .Nm atf-check
@@ -275,7 +325,7 @@
 For more details on the parameters of this function, refer to
 .Xr atf-check 1 .
 .Pp
-.Fn atf_check_equal expr1 expr2
+.Ic atf_check_equal expr1 expr2
 .Pp
 This function takes two expressions, evaluates them and, if their
 results differ, aborts the test case with an appropriate failure message.