aboutsummaryrefslogtreecommitdiff
path: root/doc/testscript.cli
diff options
context:
space:
mode:
Diffstat (limited to 'doc/testscript.cli')
-rw-r--r--doc/testscript.cli71
1 files changed, 36 insertions, 35 deletions
diff --git a/doc/testscript.cli b/doc/testscript.cli
index deeba89..921a0f1 100644
--- a/doc/testscript.cli
+++ b/doc/testscript.cli
@@ -104,7 +104,7 @@ testscript file tests a specific target we simply list it as a target's
prerequisite, for example:
\
-exe{hello}: cxx{hello} test{testscript}
+exe{hello}: cxx{hello} testscript
\
Let's assume our \c{hello} program expects us to pass the name to greet as a
@@ -482,9 +482,9 @@ platform test to \c{buildfile}:
\
# buildfile
-exe{hello}: cxx{hello} test{testscript}
+exe{hello}: cxx{hello} testscript
-test{*}: windows = ($cxx.target.class == windows)
+testscript{*}: windows = ($cxx.target.class == windows)
\
\
@@ -612,13 +612,14 @@ prerequisite that describes how to test the target similar to how, for
example, the \c{INSTALL} file describes how to install it. For example:
\
-exe{hello}: test{testscript} doc{INSTALL README}
+exe{hello}: testscript doc{INSTALL README}
\
By convention, the testscript file should be called either \c{testscript} if
-you only have one or have the \c{.test} extension, for example,
-\c{basics.test}. The \c{test} module registers the \c{test{\}} target type to
-be used for testscript files.
+you only have one or have the \c{.testscript} extension, for example,
+\c{basics.testscript}. The \c{test} module registers the \c{testscript{\}}
+target type to be used for testscript files. We don't have to use explicit
+target type for the \c{testscript} file.
A testscript prerequisite can be specified for any target. For example, if
our directory contains a bunch of shell scripts that we want to test together,
@@ -626,22 +627,22 @@ then it makes sense to specify the testscript prerequisite for the directory
target:
\
-./: test{basics}
+./: testscript{basics}
\
During variable lookup if a variable is not found in one of the testscript
scopes (see \l{#model Model and Execution}), then the search continues in the
\c{buildfile} starting with the target-specific variables of the target being
tested (e.g., \c{exe{hello\}}; called \i{test target}), then target-specific
-variables of the testscript target (e.g., \c{test{basics\}}; called \i{script
-target}), and then continuing with the scopes starting with the one containing
-the script target. As a result, a testscript can \"see\" all the existing
-buildfile variables plus we can use target-specific variables to pass
+variables of the testscript target (e.g., \c{testscript{basics\}}; called
+\i{script target}), and then continuing with the scopes starting with the one
+containing the script target. As a result, a testscript can \"see\" all the
+existing buildfile variables plus we can use target-specific variables to pass
additional, test-specific, information to testscrips. As an example, consider
this testscript and buildfile pair:
\
-# basics.test
+# basics.testscript
if ($cxx.target.class == windows)
test.arguments += $foo
@@ -655,19 +656,19 @@ end
\
# buildfile
-exe{hello}: test{basics}
+exe{hello}: testscript{basics}
# All testscripts in this scope.
#
-test{*}: windows = ($cxx.target.class == windows)
+testscript{*}: windows = ($cxx.target.class == windows)
# All testscripts for target exe{hello}.
#
exe{hello}: bar = BAR
-# Only basics.test.
+# Only basics.testscript.
#
-test{basics}@./: foo = FOO
+testscript{basics}@./: foo = FOO
\
Additionally, by convention, a number of pre-defined \c{test.*} variables are
@@ -678,7 +679,7 @@ variable is automatically set to the target path being tested. For example,
given this \c{buildfile}:
\
-exe{hello}: test{testscript}
+exe{hello}: testscript
\
The value of \c{test} inside the testscript will be the absolute path to the
@@ -704,7 +705,7 @@ This is how we can implement \c{tests/buildfile} for this setup:
\
hello = ../hello/exe{hello}
-./: $hello test{testscript}
+./: $hello testscript
./: test = $hello
include ../hello/
@@ -762,8 +763,8 @@ directory, then the subdirectory is called \c{test}. Otherwise, it is the name
of the target prefixed with\c{test-}. For example:
\
-./: test{foo} # $out_base/test/
-exe{hello}: test{bar} # $out_base/test-hello/
+./: testscript{foo} # $out_base/test/
+exe{hello}: testscript{bar} # $out_base/test-hello/
\
@@ -787,8 +788,8 @@ A scope (both group and test) has an \i{id}. If not specified explicitly (as
part of the description), it is derived automatically from the group/test
location in the testscript file (see \l{#syntax-description Description} for
details). The id of the implicit outermost scope is the script file name
-without the \c{.test} extension, except if the file name is \c{testscript},
-in which case the id is empty.
+without the \c{.testscript} extension, except if the file name is
+\c{testscript}, in which case the id is empty.
Based on the ids each nested group and test has an \i{id path} that uniquely
identifies it. It starts with the id of the implied outermost group (unless
@@ -799,7 +800,7 @@ temporary directory where the test is executed (as described below). Inside a
scope its id path is available via the special \c{$@} variable (read-only).
As an example, consider the following testscript file which we assume is
-called \c{basics.test}:
+called \c{basics.testscript}:
\
test0: test0
@@ -861,9 +862,9 @@ is not empty, then the test is considered to have failed (unexpected output).
Inside a scope its working directory is available via the special \c{$~}
variable (read-only).
-As an example, consider the following version of \c{basics.test}. We also
-assume that its test target is a directory (so the target test directory is
-\c{$out_base/test/}).
+As an example, consider the following version of \c{basics.testscript}. We
+also assume that its test target is a directory (so the target test directory
+is \c{$out_base/test/}).
\
: group
@@ -960,7 +961,7 @@ the teardown commands are executed sequentially and in the order specified.
Again, if any of them fail, the group execution is terminated and the group is
considered to have failed.
-As an example, consider the following version of \c{basics.test}:
+As an example, consider the following version of \c{basics.testscript}:
\
test0
@@ -1016,7 +1017,7 @@ for this example:
A testscript would normally contain multiple tests and sometimes it is
desirable to only execute a specific test or a group of tests. For example,
you may be debugging a failing test and would like to re-run it. As an
-example, consider the following testscript file called \c{basics.test}:
+example, consider the following testscript file called \c{basics.testscript}:
\
$* foo : foo
@@ -1037,10 +1038,10 @@ basics/fox/baz
\
To only run individual tests, test groups, or testscript files we can specify
-their id paths in the \c{config.test} variable, for example:
+their id paths in the \c{config.testscript} variable, for example:
\
-$ b test config.test=basics # All in basics.test
+$ b test config.test=basics # All in basics.testscript
$ b test config.test=basics/fox # All in fox
$ b test config.test=basics/foo # Only foo
$ b test 'config.test=basics/foo basics/fox/bar' # Only foo and bar
@@ -1624,7 +1625,7 @@ variable is assigned. You can, however, use variables assigned in the
buildfile. For example:
\
-include common-$(cxx.target.class).test
+include common-$(cxx.target.class).testscript
\
\h2#syntax-directive-include|Include|
@@ -2827,9 +2828,9 @@ tests. It is also a good idea to give the summary of the group, for example:
\
In the same vein, don't repeat the testscript id in group or test ids. For
-example, if the above tests were in the \c{greeting.test} testscript, then
-using \c{custom-greeting} as the group id would be unnecessarily repetitive
-since the id path would then become \c{greeting/custom-greeting/john}, etc.
+example, if the above tests were in \c{greeting.testscript}, then using
+\c{custom-greeting} as the group id would be unnecessarily repetitive since
+the id path would then become \c{greeting/custom-greeting/john}, etc.
We quote values that are \i{strings} as opposed to options, file names, paths
(unless contain spaces), integers, or boolean. When quoting, use the single