CMDTEST(1)
β¨ CMDTEST(1) β¨
okay bestie, sit down, hydrate, because we're about to talk about cmdtest β straight out of the General Commands Manual π and honestly? it's giving "quietly running your entire test suite while you sleep" energy.
πΈ NAME πΈ
cmdtest β blackbox testing of Unix command line tools π¦
No cap. That's the whole job description.
π SYNOPSIS π
cmdtest [-cCOMMAND] [--command=COMMAND] [--config=FILE] [--dump-config]
[--dump-setting-names] [--generate-manpage=TEMPLATE] [-h] [--help]
[--help-all] [--list-config-files] [--version] [--no-default-configs]
[--dump-memory-profile=METHOD] [-k] [--keep] [--no-keep] [--log=FILE]
[--log-keep=N] [--log-level=LEVEL] [--log-max=SIZE] [--log-mode=MODE]
[--memory-dump-interval=SECONDS] [--output=FILE] [-tTEST] [--test=TEST]
[--timings] [--no-timings] [FILE]...
π DESCRIPTION π
So, cmdtest black box tests Unix command line tools. Black box meaning: it doesn't peek inside, it just feeds your tool stuff and checks the vibes on the way out. You hand it some test scripts, their inputs, and expected outputs, and it verifies that the command line produces the expected output. And if it doesn't? π It reports problems and shows you the differences. (The diff is the moment of truth, fr.)
Each test case foo consists of the following files:
foo.scriptβ a script to run the test (this is required, like genuinely non-negotiable)foo.stdinβ the file fed to standard inputfoo.stdoutβ the expected output to the standard outputfoo.stderrβ the expected output to the standard errorfoo.exitβ the expected exit codefoo.setupβ a shell script to run before the testfoo.teardownβ a shell script to run after test
Usually, a single test is not enough. (Real.) All tests are put into the same directory, and they may share some setup and teardown code:
setup-onceβ a shell script to run once, before any testssetupβ a shell script to run before each testteardownβ a shell script to run after each testteardown-onceβ a shell script to run once, after all tests
cmdtest is given the name of the directory with all the tests, or several such directories, and it does the following:
- execute
setup-once - for each test case (unique prefix
foo):- execute
setup - execute
foo.setup - execute the command, by running
foo.script, and redirecting standard input to come fromfoo.stdin, and capturing standard output and error and exit codes - execute
foo.teardown - execute
teardown - report result of test: does exit code match
foo.exit, standard output matchfoo.stdout, and standard error matchfoo.stderr?
- execute
- execute
teardown-once
Except for foo.script, all of these files are optional. π«Ά If a setup or teardown script is missing, it is simply not executed. If one of the standard input, output, or error files is missing, it is treated as if it were empty. If the exit code file is missing, it is treated as if it specified an exit code of zero. (Defaulting to success? iconic behavior honestly.)
The shell scripts may use the following environment variables:
DATADIRβ a temporary directory where files may be created by the testTESTNAMEβ name of the current test (will be empty forsetup-onceandteardown-once)SRCDIRβ directory from whichcmdtestwas launched
β¨ OPTIONS β¨
-c,--command=COMMANDβ ignored for backwards compatibility--generate-manpage=TEMPLATEβ fill in manual page TEMPLATE-h,--helpβ show this help message and exit-k,--keepβ keep temporary data on failure--no-keepβ opposite of--keep--output=FILEβ write output to FILE, instead of standard output-t,--test=TESTβ run only TEST (can be given many times)--timingsβ report how long each test takes--no-timingsβ opposite of--timings--versionβ show program's version number and exit
π§ Configuration files and settings π§
--config=FILEβ add FILE to config files--dump-configβ write out the entire current configuration--dump-setting-namesβ write out all names of settings and quit--help-allβ show all options--list-config-filesβ list all possible config files--no-default-configsβ clear list of configuration files to read
π Logging π
--log=FILEβ write log entries to FILE (default is to not write log files at all); use"syslog"to log to system log,"stderr"to log to the standard error output, or"none"to disable logging--log-keep=Nβ keep last N logs (10)--log-level=LEVELβ log at LEVEL, one ofdebug,info,warning,error,critical,fatal(default:debug)--log-max=SIZEβ rotate logs larger than SIZE, zero for never (default: 0)--log-mode=MODEβ set permissions of new log files to MODE (octal; default0600)
π Peformance π
yes bestie, that's exactly how it's spelled in the manual. we do not fix, we only transcribe. π
--dump-memory-profile=METHODβ make memory profiling dumps using METHOD, which is one of:none, orsimple(no meliae support anymore)(default:simple)--memory-dump-interval=SECONDSβ make memory profiling dumps at least SECONDS apart
π₯ EXAMPLE π₯
To test that the echo(1) command outputs the expected string, create a file called echo-tests/hello.script containing the following content:
#!/bin/sh
echo hello, world
Also create the file echo-tests/hello.stdout containing:
hello, world
Then you can run the tests:
$ cmdtest echo-tests
test 1/1
1/1 tests OK, 0 failures
If you change the stdout file to be something else, cmdtest will report the differences:
$ cmdtest echo-tests
FAIL: hello: stdout diff:
--- echo-tests/hello.stdout 2011-09-11 19:14:47 +0100
+++ echo-tests/hello.stdout-actual 2011-09-11 19:14:49 +0100
@@ -1 +1 @@
-something else
+hello, world
test 1/1
0/1 tests OK, 1 failures
Furthermore, the echo-tests directory will contain the actual output files, and diffs from the expected files. If one of the actual output files is actually correct, you can actually rename it to be the expected file. Actually, that's a very convenient way of creating the expected output files: you run the test, fixing things, until you've manually checked the actual output is correct, then you rename the file. (the triple "actually" is canon, bestie. we keep the facts AND the flavor.)
π SEE ALSO π
and that's the whole page, bestie π«Ά this one came from the General Commands Manual, it's CMDTEST(1), and that's the sign-off β no extra lore, no secret footnotes, just the man page and its title. periodt. π
β¨
π¦ where this page comes from
- debian bookworm: cmdtest 0.32.14.gcdfe14e-5 Β· GPL-3.0-or-later
- ubuntu jammy: cmdtest 0.32.14.gcdfe14e-2 Β· GPL-3.0-or-later
- ubuntu noble: cmdtest 0.32.14.gcdfe14e-6 Β· GPL-3.0-or-later
- Copyright 2011 Lars Wirzenius <liw@liw.fi>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms