|
NAMEkyua —
Testing framework for infrastructure software
SYNOPSIS
DESCRIPTIONIf you are here looking for details on how to run the test suite in /usr/tests (or /usr/local/tests), please start by reading the tests(7) manual page that should be supplied by your system.Kyua is a testing framework for infrastructure software, originally designed to equip BSD-based operating systems with a test suite. This means that Kyua is lightweight and simple, and that Kyua integrates well with various build systems and continuous integration frameworks. Kyua features an expressive test suite definition language, a safe runtime engine for test suites and a powerful report generation engine. Kyua is for both developers and users, from the developer applying a simple fix to a library to the system administrator deploying a new release on a production machine. Kyua is able to execute test programs written with a plethora of testing libraries and languages. The library of choice is ATF, for which Kyua was originally designed, but simple, framework-less test programs and TAP-compliant test programs can also be executed through Kyua. OverviewAs can be observed in the synopsis, the interface ofkyua implements a common subcommand-based interface.
The arguments to the tool specify, in this order: a set of common options that
all the commands accept, a required command name that
specifies what kyua should do, and a set of
possibly-optional command_options and
command_arguments that are specific to the chosen
command.
The following options are recognized by all the commands. Keep in mind that these must always be specified before the command name.
The following commands are generic and do not have any relation to the execution of tests or the inspection of their results:
The following commands are used to generate reports based on the data previously recorded in a results file:
The following commands are used to interact with a test suite:
Loggingkyua has a logging facility that collects all kinds of
events at run time. These events are always logged to a file so that the log
is available when it is most needed: right after a non-reproducible problem
happens. The only way to disable logging is by sending the log to
/dev/null.
The location of the log file can be manually specified with the
And the default naming scheme of the log files is: ‘<progname>.<timestamp>.log’. The messages stored in the log file have a level (or severity) attached to them. These are:
The default log level is ‘info’ unless expicitly
overriden with The log file is a plain text file containing one line per log record. The format of each line is as follows: timestamp entry_type pid file:line: message entry_type can be one of: ‘E’ for an error, ‘W’ for a warning, ‘I’ for an informational message and ‘D’ for a debug message. Bug reportingIf you think you have encountered a bug inkyua , please
take the time to let the developers know about it. This will ensure that the
bug is addressed and potentially fixed in the next Kyua release.
The first step in reporting a bug is to check if there already is a similar bug in the database. You can check what issues are currently in the database by going to: https://github.com/jmmv/kyua/issues/ If there is no existing issue that describes an issue similar to the one you are experiencing, you can open a new one by visiting: https://github.com/jmmv/kyua/issues/new/ When doing so, please include as much detail as possible. Among
other things, explain what operating system and platform you are running
Also, please include a copy of the log file corresponding to the problem you are experiencing. Unless you have changed the location of the log files, you can most likely find them in ~/.kyua/logs/. If the problem is reproducible, it is good idea to regenerate the log file with an increased log level so as to provide more information. For example: $ kyua --logfile=problem.log --loglevel=debug \ [rest of the command line] ENVIRONMENTThe following variables are recognized and can be freely tuned by the end user:
The following variables are also recognized, but you should not
need to set them during normal operation. They are only provided to override
the value of built-in values, which is useful when testing
FILES
EXIT STATUSkyua returns 0 on success, 1 on a controlled error
condition in the given subcommand, 2 on a general unexpected error and 3 on a
usage error.
The documentation of the subcommands in the corresponding manual pages only details the difference between a successful exit (0) and the detection of a controlled error (1). Even though when those manual pages do not describe any other exit statuses, codes above 1 can be returned. SEE ALSOkyua.conf(5), kyuafile(5), atf(7), tests(7)AUTHORSFor more details on the people that madekyua possible
and the license terms, run:
$ kyua about
Visit the GSP FreeBSD Man Page Interface. |