-
Notifications
You must be signed in to change notification settings - Fork 7
/
README
91 lines (62 loc) · 3.28 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
Extracted from http://code.google.com/p/nodediag/wiki/Writing_Tests:
Tests that are installed in /etc/nodediag.d will be executed by the
nodediag script. A test could be provided by another package, added by
cfengine, or provided by the nodediag package. This document explains how
to write a test.
Test Protocol
nodediag tests use the Test Anything Protocol (TAP). This is a quasi-standard
that emerged from the perl community. The testanything.org wiki provides
background and details on TAP. The TAP specification page describes TAP
output format.
In addition to TAP formatted output, nodediag tests must handle three
arguments:
-d Produce a one-line description of the test’s purpose.
-c Produce default output for the /etc/sysconfig/nodediag file for this test.
-s Run only a sanity (quick) version of the test.
Tests normally exit with a return code of zero, regardless of whether tests
failed. If they exit with a nonzero return code, the test framework may
flag them as suspect.
TAP tests should be named with a .t suffix.
You can run a test script directly and observe the output that is produced.
The same output is shown when you invoke nodediag -v.
Convenience Functions
Tests written in bash may source a set of convenience functions in
/etc/nodediag.d/functions-tap. This causes the config files
/etc/sysconfig/nodediag and /etc/sysconfig/nodediag.d/testname, if any,
to be sourced so that those variables can be referenced in the test.
Users should define $description as a one-line prose description of the
test, then source /etc/nodediag.d/functions-tap.
To handle the required arguments, call diag_handle_args "$@".
-d: $description is printed on stdout.
The -d output of all the tests is folded together when
you run nodediag -l.
-s: the accessor function diag_sanity() will return true should your
script call it later on. The sanity option indicates that long
running tests should be skipped
-c: a shell function diagconfig() will be called, if defined.
This function emits default settings for this test's configuration.
The -c output of all the tests is folded together when you run
nodediag -c, which becomes a template for /etc/sysconfig/nodediag.
If the test must be aborted call
diag_plan_skip reason
otherwise call
diag_plan n
where n is the number of subtests that will be run. This number must match
the number of calls to diag_ok, diag_fail, diag_skip, and diag_todo.
For each subtest, call one of the above result reporting functions, e.g.
diag_ok successfully tested thingie
The diag_msg function can be used to print debugging info which is visible
in the raw test output (nodediag -v).
When the subtests are comlete, call exit 0.
For a simple example with only one subtest, see diags/cpucount.t.
Its output looks like this:
1..1
ok 1 - cpucount: cpucount 4
For a more complicated example, see diags/hdparm.t. This test uses a
bash array for configuring multiple devices to test. It is skipped if
not run as root or if the -s,--sanity option was passed to nodediag.
The number of subtests depends on the number of devices configured.
Its output looks like this:
1..2
ok 1 - hdparm: /dev/mapper/sil_bhafebacddbh speed 258 MB/s
ok 2 - hdparm: /dev/mapper/vg_mrhankey-lv_root speed 124 MB/s