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