NAME
App::TestOnTap::Args
Commandline options and arguments understood for TestOnTap processing
SYNOPSIS
testontap
[
--usage | -?
|
--help
|
--manual
|
--version
]
[ -v | --verbose [ -v ... ] ]
[ --workdirectory <path> ]
[ --include <query> ]
[ --jobs <n> ]
[ --timer ]
[ --execmap <mapfile> ]
[ --archive ]
[ --savedirectory <path> ]
[ --define | -D <key>=<value> [ --define ... ] ]
<suitepath>
[<suiteargs> ...]
OPTIONS AND ARGUMENTS
All options can be abbreviated, as long as they are unambiguous. Option matching is case sensitive. Forcibly end option parsing using '--'.
- Information options
-
If any of these options are given, the rest of the command line is ignored.
If multiple of these options are given only one will be acted on, in the order --manual, --help, --usage and --version.
- -v, --verbose
-
By default, the output will be regular test output after consuming TAP (e.g. timings, ok/fail messages, summary etc).
Using this option allows the pass through of more verbose output from the tests themselves.
To up verbosity, add one or more verbose flags (bundling for singlecharacter options is on, so '-vvv' is the same as '-v -v -v'). Currently, up to verbosity level 1 is used.
- --workdirectory <path>
-
By default, a temporary directory is created to hold the data produced by the tests and is automatically removed when the run is complete.
Use this option if you want to keep the work dir after completion (for debugging/perusal/whatever). The path must not exist beforehand.
For details of the work directory, see the manual regarding 'persisted results'.
- --include <query>
-
By default, all tests will be run (subject to selection by the
execmap
in effect and the internally configured include).By providing a query, a subset of those tests can be manually selected. However, be aware that actual tests selected are also subject to any dependencies declared between tests - e.g. a query selecting only test A will effectively also select test B if there is a A => B dependency in the config.
For more on selecting tests, see the manual regarding the 'include' config setting.
- --jobs <n>
-
By default, tests will run in sequence, governed by any dependencies, and sorted alphabetically. Also by default, they will always run serially.
By setting this option to a value higher than 1 allowing a maximum of n jobs to execute concurrently. However, for this to take effect, a
parallelizable
rule must be in the suite configuration in order to select which tests actually can run in parallelThe actual amount of concurrently executing jobs are then subject to limiting factors, such as dependencies and the parallelizability of a given test.
For more on parallelization, see the manual regarding the 'parallelizable' config setting.
- --execmap <mapfile>
-
By default, the test suite will be searched for 'executables' based on the exec map defined in the suite, or a built in default if none defined.
This option allows overriding the choices of the suite/internal exec map.
For more on execmaps, see the manual regarding the 'execmap section' config setting.
- --archive, --savedirectory <path>
-
By default, the results of a test run are not saved.
By providing either or both of these options, results may be saved as either a ready-made archive or a regular directory. The name of the saved file/directory will be named using the basename of the suite plus a timestamp and the run id, which together should be entirely unique.
Giving only
--archive
, the result will be saved as an archive in the current directory.Giving
--archive --savedirectory some/path
together, the result will be saved as an archive in the directory some/path (the directory may or may not exist beforehand).Giving only
--savedirectory some/path
, the result archive will be a regular subdirectory in the directory some/path (the directory may or may not exist beforehand).For details of saved results, see the manual regarding 'persisted results'.
- --define <key>=<value>
-
The function of this option is to make it possible to pass on arbitrary key/value pairs to a saved result in order to later enable various types of differentiation to be made when processing the saved result. The defines are not made available to tests.
Can be given multiple times.
- suitepath
-
This is the path to the root of the suite. The root must contain a valid testontap configuration file.
For details on test suites, see the manual.
- suiteargs ...
-
Any arguments can be passed, and they will just be passed on as-is to the tests when they start.
For details, see the manual on parameter passing.
MORE HELP
For full information on TestOnTap, see the manual, or use --manual or run perldoc App::TestOnTap to see the manual page.