bstinson / centos / t_functional

Forked from centos/t_functional 4 years ago
Clone
Blob Blame History Raw
This Git repo contains all the functional tests run for various packages and roles in the CentOS build + release process

filesystem layout:

tests/         : contains all test scripts

tests/0_lib/   : contains all the common functions and shared code for 
                 the tests all files in that directory are 'sourced' 
                 before any of the tests are run, which also means it 
                 can only contain bash code ( no subdir allowed )

tests/_common/ : Contain's testst that are run before any other test,
                 and immediately after the 0_lib/ code is sourced.
                 These should be tests that check system sanity and 
                 environment. These tests should also not leave behind
                 any state or content residue that would impact package
                 and role specific tests that are run after

tests/p_<name>/ : Each of the p_<name> directories would contain tests
                  for that specific package. The <name> needs to be -
                  rpm --qf "%{name}\n" for the srpm.

                  All package tests are run on a machine which has a minimal
                  install. Its not possible, at this time, to have a kickstart
                  attached with the package tests.

tests/r_<role>  : Each of the r_<role> directories should contain the tests
                  specific to a role. eg: 'lamp'. The test harness looks at
                  a file called 'pacakge_deps' inside each of the role directories
                  and runs the role tests if any package listed in that file 
                  has been changed / built etc.

                  Role tests can be run with specific kickstarts. At the moment
                  each role can have 1 kickstart file. It must be called 
                  ks_<role>.cfg and it must be in the tests/r_<role>/ directory
    
notes...
- each of the directories are parsed in alphabetical order, so its possible
  to set some sort of a run order by using <number>_<TestName>

- if tests are written in any language other than bash, its upto the test
  to install the required environment ( including python, ruby, perl.. )

- all files named 'readme', or starting with an underscore are ignored 
  by the test harness ( so one can use the _<filename> to host metadata
  or any config that might be needed for a test.