278N/A# This file and its contents are supplied under the terms of the
278N/A# Common Development and Distribution License ("CDDL"), version 1.0.
278N/A# You may only use this file in accordance with the terms of version
278N/A# A full copy of the text of the CDDL should have accompanied this
278N/A# source. A copy of the CDDL is also available via the Internet at
278N/A# Copyright (c) 2013 by Delphix. All rights reserved.
278N/A2. How to Run These Tests
278N/A3. How to Develop New Tests
2363N/A4. Porting Tests from Other Frameworks
278N/A--------------------------------------------------------------------------------
618N/AThe tests here come in two varieties - tests written from scratch, and tests
278N/Athat have been ported from the Solaris Test Collection. Not all of the STC
278N/Atests have been ported, and a forked repository of those that have been made
844N/Apublicly available may currently be found here:
278N/ARegardless of origin, all of these tests are executed using the run(1) script
278N/Adescribed in the next section.
278N/A2. How to Run These Tests
278N/Aaround run(1). These wrappers allow environment variables to be set up which
278N/Amay (for example) allow the script to specify which disks may be used by a test
278N/Asuite, and which must be preserved. Additionally, the wrappers allow options to
278N/Arun(1) to be passed through so that a user may specify a custom configuration
278N/Afile for a test suite. For specifics on the options available in the framework
278N/Aitself, please see the run(1) manpage.
278N/A3. How to Develop New Tests
1845N/ANew tests should mimic the directory layout of existing tests to the degree
1845N/Apossible. This includes the following directories:
278N/Acmd - Any support binaries or scripts used by the tests in this package.
1938N/Adoc - READMEs or other support documentation to be delivered with the package.
1938N/Arunfiles - Configuration files that dictate how the tests are run.
278N/Atests - The tests themselves (see below).
278N/AThe tests you create will be run, and given a PASS or FAIL status in accordance
278N/Awith the exit value returned by the test. A test may also be marked SKIPPED in
278N/Athe event that a prerequisite test is marked FAIL, or marked KILLED in the
278N/Aevent the test times out. Note that there is no way to force a test to be
278N/Amarked SKIPPED; this is intentional. If a test must be skipped due to
278N/Ainsufficient resources for example, then a wrapper script should be provided
278N/Athat chooses or creates an appropriate configuration file. The goal of every
run is that every test is marked PASS.
4. Porting Tests from Other Frameworks
STF (Solaris Test Framework)
Porting tests from this framework is relatively straightforward. For the most
part the tests can be arranged in the new directory structure and added to the
configuration file. The template for a configuration file can easily be created
using the -w option to run(1). There are a few other changes that may be
Some STF tests consume the values of variables from the user's environment.
These variables must be set before beginning the test run either manually, or
Groups of tests in STF can automatically source .cfg files specified in the
'stf_description' file that exists in an STF directory. Ported tests that
require any of these variables must manually source the .cfg file instead.
The configuration file of a newly ported test must specify the user the test
should run as, along with the timeout value. In STF, these are also specified
in the 'stf_description' file.