This file provides some basic guidance on things to consider when writing test scripts for the QA process:

- scripts should exit with either zero to signal success, or a non-zero value to signal failure. A failure exit code causes the entire test script execution process to stop (which is fine - we need to see what failed)

- you can use any language to write test scripts, but at present, the largest collection of helper functions are available to Bash/sh scripts. If the language you intend to use isn't available by default, the first thing you test script should do is yum install <language packages>.

- several helper functions are available in test/0_lib/*. Please use these in preference to directly calling any of the commands they implement. You don't have to source the file in your test scripts, just call/use the functions as required. The helper functions are there (for example) to promote consistency in debugging output and help avoid timing related test failures eg, daemons not being given sufficient time to start before testing for their existence. Please review the contents of 0_lib/ so you're familiar with what's on offer.

- if you're using Bash, the first thing you should ideally do is make a call to t_Log, passing in $0 and a description of what the test is doing, something like:

        t_Log "Running $0 - Postfix SMTP test."

- test scripts are processed in alphabetical order, so it's sensible to install any required packages in a 0-install-blah.sh script. 

- anything starting with a _ is ignored, and so are files named `readme` (case insensitive). If you need a file to store config values or any kind of metadata that's used in your test script, it probably makes sense to put it in a file starting with _ and then sourcing/including it in your test script.

- all test scripts should be chmod +x in order to be executed. Equally, removing execute permissions from a script will prevent it from being run (or prefixing it with an _, both approaches work)

- please include a suitable #Author <youremail@address.com> comment line in your test scripts, so we know who to contact in the event of questions/changes/issues.

- try and keep stdout/debugging messages generated by your test scripts to a minimum.