Description

GINT supports automatic loading of properties from gint.properties found in standard locations. Properties are automatically available to scripts as global variables (a standard GANT feature from ANT) and can be overridden by command line parameters. This makes it easy to customize GINT behavior and provides testcases with a standard way to get configuration and environmental settings that need to be isolated from the script. This is extremely important especially for integration testing. GINT Profiles provides more sophisticated support in this area as well. Property files are loaded during gint.initialize processing and are available to the test script after this point. ANT property expansion can be used - this means that properties can be referenced in other properties.

gint.properties files can be located in number of directories, all files found will be loaded in the following order:

1. User's home directory
2. Current directory
3. Project defined - the first gint.properties file found from the following
   • targetDirectory property specified from test script, command line parameter, previously loaded gint.properties, or default location - target if directory exists or current directory
   • resourceDirectory property specified or defaulted (resources in the sourceDirectory)

Property file loading is designed so default behavior will support either:

• A simple, current directory based project environment
• A standard MAVEN directory structure (if it exists)

  • Specifically supports MAVEN resource filtering of the gint.properties file allowing injection of MAVEN variables into properties available to test scripts. The MAVEN pom needs to be modified for filtering integration test resources:

    <resources>
        <resource>
            <directory>src/itest/resources</directory>
            <filtering>true</filtering>
            <includes>
                <include>gint.properties</include>
            </includes>
       </resource>
    </resources>
    

    Integration test location

    • GINT extended the standard Maven structure to have integration test source located in src/itest
    • There didn't appear to be any consensus on where integration tests should be located
    • This can be easily customized in GINT by setting sourceDirectory in gint.properties.

Example gint.properties

The following shows commented out settings to show defaults.

# Properties
# Properties are used for customization. Both GINT defined and user defined properties can be provided here.
# This serves to document GINT property values that can be used for customization
# GINT properties are commented out to document their default values
# Also see online documentation
# Properties are evaluated during gint.initialize()

# Directories for running integration tests
# By default, all directories are relative to the current directory (usually the project directory)
# The directory defaults differ depending on contents of the current directory. If the current directory looks like
# a standard Maven project structure, then the following defaults apply. Otherwise defaults are derived from the current directory.
#sourceDirectory = src/itest
#targetDirectory = target
#resourceDirectory = ${sourceDirectory}/resources
#outputDirectory = ${targetDirectory}/output
#compareDirectory = ${outputDirectory}
#testReportsDirectory = ${targetDirectory}/test-reports
#diffCmd = diff -y --suppress-common-lines

# Custom gint properties are evaluated after user home gint.properties and current directory gint.properties
#gintProperties = ${resourceDirectory}/gint.properties

# Profiles
#profiles =
#directories = ${ant.project.properties.'user.home'}, ${targetDirectory}, ${resourceDirectory}, .

# Control options
#stopOnFail = false
#noTearDown = false
#clean = false
#verbose = false
#level = 1
#maxParallel = 8
#maxThreads = ${maxParallel}
#xmlReport =
#label =
#compareLabel =
#prefix = z

Recommended Usage 

Properties including command line parameters can be used directly in scripts line any script defined variables.

myProperty = text example

println myProperty

However, if myProperty is not defined as a property either in property files or as a command line parameter, then the script will fail immediately. For testcases, you do not want failures like this, you always want testcases to complete one way (success ) or the other (failure ) so that reporting can be done properly. If the value is explicitly needed, it is better to use testcase logic to determine what should be done - perhaps just fail a specific testcase, skip the testcase, or fail the entire test. There is an easy way to do this:

def myProperty = helper.getParameterValue('myProperty')  // myProperty will always be available now
def myProperty = helper.getParameterValue('myProperty', "default value") // if not defined, use the default value
def myProperty = helper.getBooleanParameterValue('myProperty')  // true only if the value is defined and not false