9 B<tesh> [I<options>]... I<testsuite>
13 Tesh is the testing shell, a specialized shell for running tests. It
14 provides the specified input to the tested commands, and check that
15 they produce the expected output and return the expected value.
20 --cd some/directory : ask tesh to switch the working directory before
22 --setenv var=value : set a specific environment variable
23 --cfg arg : add parameter --cfg=arg to each command line
24 --log arg : add parameter --log=arg to each command line
25 --enable-coverage : ignore output lines starting with "profiling:"
28 =head1 TEST SUITE FILE SYTAX
30 A test suite is composed of one or several I<command blocks> separated
31 by empty lines, each of them being composed of a command to run, its
32 input text and the expected output.
34 The first char of each line specifies the type of line according to
35 the following list. The second char of each line is ignored.
37 `$' command to run in foreground
38 `&' command to run in background
40 `<' input to pass to the command
41 `>' output expected from the command
43 `!' metacommand, which can be one of:
44 `timeout' <integer>|no
45 `expect signal' <signal name>
46 `expect return' <integer>
47 `output' <ignore|display>
48 `output sort' [integer]
52 `p' an informative message to print
55 If the expected output do not match the produced output, or if the
56 command did not end as expected, Tesh provides an error message (see
57 the OUTPUT section below) and stops.
59 =head2 Command blocks examples
61 In a given command block, you can declare the command, its input and
62 its expected output in the order that you see fit.
76 You can group several commands together, provided that they don't have
82 =head2 Enforcing the command return code
84 By default, Tesh enforces that the tested command returns 0. If not,
85 it fails with an appropriate message and returns I<code+40> itself.
87 You specify that a given command block is expected to return another
90 # This command MUST return 42
94 The I<expect return> construct applies only to the next command block.
96 =head2 Commands that are expected to raise signals
98 By default, Tesh detects when the command is killed by a signal (such
99 as SEGV on segfaults). This is usually unexpected and unfortunate. But
100 if not, you can specify that a given command block is expected to fail
101 with a signal as follows:
103 # This command MUST raise a segfault
104 ! expect signal SIGSEGV
105 $ ./some_failing_code
107 The I<expect signal> construct applies only to the next command block.
111 By default, no command is allowed to run more than 5 seconds. You can
112 change this value as follows:
114 # Allow some more time to the command
116 $ ./some_longer_command
118 You can also disable the timeout completely by passing "no" as a value:
120 # This command will never timeout
122 $ ./some_very_long_but_safe_command
124 =head2 Setting environment variables
126 You can modify the environment of the tested commands as follows:
131 You can also set an envirmnent variable from the command line:
133 tesh --setenv bindir=/opt/bin/
135 And then use it within the tesh file:
137 $ ${bindir}/myprogram
139 Tesh also supports perl default value for undefined variables:
141 $ ${bindir:=/usr/bin}/myprogram
143 =head2 Not enforcing the expected output
145 By default, the commands output is matched against the one expected,
146 and an error is raised on discrepancy. Metacommands to change this:
152 The output is completely discarded.
156 The output is displayed, but no error is issued if it differs from the
161 The output and the expected output are sorted before comparison (see next section).
165 =head2 Sorting output
167 If the order of the command output changes between runs, you want to
168 sort it before enforcing that it is exactly what you expect. In
169 SimGrid for example, this happens when parallel execution is
170 activated: User processes are run in parallel at each timestamp, and
171 the output is not reproducible anymore. Until you sort the lines.
173 You can sort the command output as follows:
176 $ ./some_multithreaded_command
178 Sorting lines this ways often makes the tesh output very intricate,
179 complicating the error analysis: the process logical order is defeated
180 by the lexicographical sort.
182 The solution is to prefix each line of your output with temporal
183 information so that lines can be grouped by timestamps. The
184 lexicographical sort then only applies to lines that occured at the
185 same timestamp. Here is a SimGrid example:
187 # Sort only lines depending on the first 19 chars
189 $ ./some_simgrid_simulator --log=root.fmt:[%10.6r]%e(%i:%P@%h)%e%m%n
191 This approach may seem surprizing at the first glance but it does its job:
195 =item Every timestamps remain separated, as it should;
197 =item In each timestamp, the output order of processes become
198 reproducible: that's the lexicographical order of their name;
200 =item For each process, the order of its execution is preserved: its
201 messages within a given timestamp are not reordered.
205 That way, tesh can do its job (no false positive, no false negative)
206 despite the unpredictable order of executions of processes within a
207 timestamp, and reported errors remain easy to analyze (execution of a
208 given process preserved).
210 This example is very SimGrid oriented, but the feature could even be
211 usable by others, who knows?
213 =head2 Ignoring some output
215 Some outputed lines can be ignored by setting the ignore command followed
216 by a regular expression:
218 ! ignore .*0x[0-9A-F]+\.
219 $ printf 'word\nMemory address: 0x42AA42.\nanotherword\n'
224 =head2 Colored and formatted text
226 Tesh removes ANSI/VT100 control sequences from outputed text to make easier the writing of tests.
228 $ printf "I \033[0;31mlove\033[0m tesh\n"
233 =head1 BUILTIN COMMANDS
235 =head2 mkfile: creating a file
237 This command creates a file of the name provided as argument, and adds
238 the content it gets as input.
244 It is not possible to use the cat command, as one would expect,
245 because stream redirections are currently not implemented in Tesh.
247 =head1 BUGS, LIMITATIONS AND POSSIBLE IMPROVEMENTS
249 The main limitation is the lack of stream redirections in the commands
250 (">", "<" and "|" shell constructs and friends). The B<mkfile> builtin
251 command makes this situation bearable.
253 It would be nice if we could replace the tesh file completely with
254 command line flags when the output is not to be verified.