Configuration

Configuration

Once Madcow is setup and running correctly, the configuration files within the conf directory will need to be changed for the particular site that you are working on.

## URL Configuration To assist in managing multiple target environments, Madcow supports single or multiple URL property files. These property files are used to substitute the URL being invoked by the Invoke Url command.

Single URL Property File

For instance, having a hard-coded URL for a Create Address page,

invokeUrl = http://test-site/address/create

can be expressed as

invokeUrl = TEST_SITE/address/create

where the TEST_SITE key is defined in the URL mappings file

TEST_SITE=http://test-site

For this example, when Madcow is executing the invokeUrl command, it will substitute TEST_SITE with http://test-site

Filename format

For a single URL property file, it must be named madcow.url.properties. There is no restriction on the number of key/value pairs in the property file.

Multiple URL Property Files

As Madcow supports multiple URL properties files, you can therefore have a collection of url files, each with a unique URL, using the same identification key to allow quick switching between target environments, without any need to change individual invokeUrl commands.

Each URL property file must be suffixed with .madcow.url.properties, however, when specifying which to use, it is only the name in front of the .madcow.url.properties postfix that is used.

So if we had two URL property files, one named development.madcow.url.properties and the other integrated.madcow.url.properties, they are referred to by development and integrated respectively.

In order to specify which URL property file to use, set the URL filename on the command line / set the relevant ant property.

Using the shell script:

./runMadcow.sh -u development
./runMadcow.sh -u integrated

Or as an ant property:

ant run-all-tests -Dmadcow.url.properties.file="development"
ant run-all-tests -Dmadcow.url.properties.file="integrated"

Filename format

For multiple URL property files, each must be suffixed with .madcow.url.properties. There is no restriction on the number of key/value pairs in the property file.

Database Configuration

The Madcow Execute SQL step allows the user execute a given SQL script into a database under test. In order to facilitate this process, Madcow will attempt to find a database properties file containing the database connection details. Madcow supports having either a single or multiple database property files.

###A single database properties file### By default, Madcow will attempt to load database properties from a file called madcow.database.properties. If only one environment is going to be tested against, then add the database properties to this file in the conf directory.

###Multiple database properties files If Madcow will be run against multiple environments, it's advisable to keep a separate database properties file for each environment.

Each database property file must be suffixed with .madcow.database.properties, and only the part of the filename in front of .madcow.database.properties needs to be supplied when specifying which properties file to use.

So, if we had two database property files, one named development.madcow.database.properties and the other integrated.madcow.database.properties, they are referred to by development and integrated respectively.

In order to specify which database properties file to use, the filename needs to be specified when running Madcow.

Using the shell script:

./runMadcow.sh -d development
./runMadcow.sh -d integrated

Or as an ant property:

ant run-all-tests -Dmadcow.database.properties.file="development"
ant run-all-tests -Dmadcow.database.properties.file="integrated"

###Required configurables### The following example file shows all of the properties that need to be set in order to have Madcow utilise database connectivity.

jdbc.className=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/madcowdatabase
jdbc.user=madcowuser
jdbc.password=madcowpassword

Setting defaults for Madcow

Once you factor in all of the possibilities for running Madcow from the command-line, it can get to be a fairly long piece of typing. In order to facilitate running Madcow with predictable values, Madcow can optionally read default values for certain configurables from conf/madcow.config.properties. Any value specified in conf/madcow.config.properties can still be overridden with the command-line arguments specified on this page, and in Running Madcow Tests.

##Valid Configurables for madcow.config.properties

madcow.browser

Specifies the internet browser that Madcow will emulate by default. This option can be overridden when running madcow, by using the -b switch followed by the browser of choice. The following are valid values for this configurable:

• InternetExplorer6
• InternetExplorer7
• Firefox3
• Firefox2

For example:

madcow.browser = Firefox3

madcow.threads

Specifies the maximum number of concurrent threads of execution that Madcow will use to execute tests (when running more than one). More threads will increase the load on both the system under test, and the system running Madcow. For example:

madcow.threads = 10

###madcow.default.url This configurable specifies the url configuration file that Madcow will use by default. If this configurable isn't set, madcow will use the url configuration in conf/madcow.url.properties by default. This configurable can be overridden when running Madcow by using the -u switch, followed by the prefix for the url configration file of choice (eg. -u DEV will use conf/DEV.madcow.url.properties). For example:

madcow.default.url = DEV

###madcow.default.database This configurable specifies the database configuration file that Madcow will use by default. If this configurable isn't set, madcow will use the database configuration in conf/madcow.database.properties by default. This configurable can be overridden when running madcow by using the -d switch, followed by the prefix for the database configuration file of choice (eg -d DEV will use conf/DEV.madcow.database.properties). For example:

madcow.default.database = localDB

madcow.proxy.url

This configurable tells Madcow to use the specified http proxy when attempting to access the site under test.

madcow.proxy.url = localhost

madcow.proxy.port

This configurable tells Madcow to use the specified port when attempting to use an http proxy to access the system under test. If this value is not set, then Madcow will attempt to use port 80. Please note - this configurable must be used in conjunction with madcow.proxy.url.

madcow.proxy.port = 80

madcow.proxy.user

This configurable tells Madcow to attempt to authenticate with the specified username when using an http proxy to access the system under test. Please note - this configurable must be used in conjunction with madcow.proxy.url.

madcow.proxy.user = joeschmoe

madcow.proxy.password

This configurable tells Madcow to attempt to authenticate with the specified password when using an http proxy to access the system under test. Please note - this configurable must be used in conjunction with madcow.proxy.url.

madcow.proxy.password = awesomeJoe66