kyua-debug(1) manual page

The kyua debug command provides a mechanism to execute a single test case bypassing some of the Kyua infrastructure and allowing the user to poke into the execution behavior of the test.

The test case to run is selected by providing a test filter, described below in Test filters, that matches a single test case. The test case is executed and its result is printed as the last line of the output of the tool.

The test executed by kyua debug is run under a controlled environment as described in Test isolation.

At the moment, the kyua debug command allows the following aspects of a test case execution to be tweaked:

Redirection of the test case's stdout and stderr to the console (the default) or to arbitrary files. See the --stdout and --stderr options below.

The following subcommand options are recognized:

--build-root path

Specifies the build root in which to find the test programs referenced by the Kyuafile, if different from the Kyuafile's directory. See Build directories below for more information.

--kyuafile file , -k file

Specifies the Kyuafile to process. Defaults to Kyuafile file in the current directory.

--stderr path

Specifies the file to which to send the standard error of the test program's body. The default is /dev/stderr, which is a special character device that redirects the output to standard error on the console.

--stdout path

Specifies the file to which to send the standard output of the test program's body. The default is /dev/stdout, which is a special character device that redirects the output to standard output on the console.

For example, consider the following Kyua session:

$ kyua test
kernel/fs:mkdir  ->  passed
kernel/fs:rmdir  ->  failed: Invalid argument

1/2 passed (1 failed)

At this point, we do not have a lot of information regarding the failure of the 'kernel/fs:rmdir' test. We can run this test through the kyua debug command to inspect its output a bit closer, hoping that the test case is kind enough to log its progress:

$ kyua debug kernel/fs:rmdir
Trying rmdir('foo')
Trying rmdir(NULL)
kernel/fs:rmdir  ->  failed: Invalid argument

Luckily, the offending test case was printing status lines as it progressed, so we could see the last attempted call and we can know match the failure message to the problem.

Process space
	Each test is executed in an independent processes. Corollary: the test can do whatever it wants to the current process (such as modify global variables) without having to undo such changes.
Session and process group
	The test is executed in its own session and its own process group. There is no controlling terminal attached to the session. Should the test spawn any children, the children should maintain the same session and process group. Modifying any of these settings prevents kyua debug from being able to kill any stray subprocess as part of the cleanup phase. If modifying these settings is necessary, or if any subprocess started by the test decides to use a different process group or session, it is the responsibility of the test to ensure those subprocesses are forcibly terminated during cleanup.
Work directory
	The test is executed in a temporary directory automatically created by the runtime engine. Corollary: the test can write to its current directory without needing to clean any files and/or directories it creates. The runtime engine takes care to recursively delete the temporary directories after the execution of a test case. Any file systems mounted within the temporary directory are also unmounted.
Home directory
	The HOME environment variable is set to the absolute path of the work directory.
Umask	The value of the umask is set to 0022.
Environment
	The LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC and LC_TIME variables are unset. The TZ variable is set to 'UTC'. The TMPDIR variable is set to the absolute path of the work directory. This is to prevent the test from mistakenly using a temporary directory outside of the automatically-managed work directory, should the test use the mktemp(3) familiy of functions.
Process limits
	The maximum soft core size limit is raised to its corresponding hard limit. This is a simple, best-effort attempt at allowing tests to dump core for further diagnostic purposes.
Configuration varibles
	The test engine may pass run-time configuration variables to the test program via the environment. The name of the configuration variable is prefixed with 'TEST_ENV_' so that a configuration variable of the form 'foo=bar' becomes accessible in the environment as 'TEST_ENV_foo=bar'.

“	What is this horrible fascination with Unix? The operating system of the 1960s, still gaining in popularity in the 1990s.	”
— Donald A. Norman

Manual Pages — KYUA-DEBUG

NAME

CONTENTS

SYNOPSIS

DESCRIPTION

Build directories

Test filters

Test isolation

EXIT STATUS

SEE ALSO

--build-root path
	Specifies the build root in which to find the test programs referenced by the Kyuafile, if different from the Kyuafile's directory. See Build directories below for more information.
--kyuafile file , -k file
	Specifies the Kyuafile to process. Defaults to `Kyuafile` file in the current directory.
--stderr path
	Specifies the file to which to send the standard error of the test program's body. The default is `/dev/stderr`, which is a special character device that redirects the output to standard error on the console.
--stdout path
	Specifies the file to which to send the standard output of the test program's body. The default is `/dev/stdout`, which is a special character device that redirects the output to standard output on the console.