Site-specific properties, setup and teardown
Author: Libor.Martinek
(libor.martinek@sun.com
)
Date: June 7, 2002
Version: 1.3
What is this document for?
This document is intended for serveral type of users.
Firstly it's intended for test developer who developes special tests
(e.g. databse tests) which needs some site-specific properties and/or setup.
There also exists examle described here.
Also it's intened for xtest administrator who will execute such
tests and has to know how to configure and use xtest to correct execution
of these tests.
What is it
Some tests has to know some information which depends on site where they
are executed. Example of such information is username, password and url
for connection to database. These information has to be provided before execution.
Also some necessary setup has to be done before test execution and teardown
after execution. Xtest support two ways of site-specific stuff.
- Passing site-specific properties for executing test for one module
(using test/build.xml)
- Configuring master-config with site-specific properties and setup/teardown
(executing whole instance).
Ad 1.
You cannot automatically perform some site-specific setup/teardown before/after
execution tests of one module (using test/build.xml), but it's supposed
that it can be easily done manually.
You can pass property file which will be used for executing test from
one module. If you use test/build.xml to execute test, just set property
xtest.userdata.propertyfile to points to property file. All properties
from this file will be loaded.
Example: ant -Dxtest.userdata.propertyfile=myfile.properties
Properties in the property file must have this format: xtest.userdata(<attrib>)|name=value
or xtest.userdata|name=value. Se Format of site-specific properties.
Ad 2.
Master config (see
Master config descr.)
was extened to support site-specific propertis and setup/teardown.
Properties
New element "property" was introduced to master-config. It can be nested
in element config or module. Element property can
has attribute file or pair of attributes name and value.
When element property is nested in element config then
all properties defined by element property are valid for whole config.
When it's nested in element module then these properties (but also
properties defined under config) are valid only for particular module. Properties
has to have again this format. See example
below
Setup
Elements config and module have new attribute setup.
Value of this attribute has to be same as attribute name of
some setup element. This setup element has two nested elements,
start and stop, which have attributes same as ant task.
This element points to code which will be executed.
When some config with attribute setup will be executed then element
start of setup will executed before test execution and element stop
will be executed after test execution. Same situation is for module
with attribute setup.
Recomended convention
Because xtest administrator will setup site-specific properties/setup of
tests which are written by test developer, it's necesssary to communicate
each other. Test developer has to say to xtest administartor which properties
and setup he needs. To help it, following convention should be kept:
- Test developer put all site-specific sample property files and setups
to directory <module>/test/site-specific.
nb_all/db/test/qa-functional/src
/site-specific/myjdbc.properties
/server_setup.xml
- XTest administrator asks test developer which property file is needed
and when execute which target of setup script. Then he puts all such file
to <xtest-instance>/site-specific/<module> and modifies
them to work on machine where tests will run.
<xtest-instance>/build.xml
/master-config.xml
/site-specific/db/jdbc.properties
oracle_setup.xml
pointbase_setup.xml
-
Finally xtest administrator modifies master-config to add all site-specific property files and setups.
Example
<config name="databases" setup="pointbase">
<property file="site-specific/pointbase.properties}"/>
<module name="db" testtypes="unit" attributes="stable,pointabse"/>
<module name="db" testtypes="unit" attributes="stable,oracle" setup="oracle"/>
<module name="jdbc" testtypes="unit" attributes="stable">
<property file="site-specific/jdbc/jdbcclient.properties"/>
</module>
</config>
<setup name="oracle">
<start antfile="site-specific/db/oracle_setup.xml" target="start"/>
<stop antfile="site-specific/db/oracle_setup.xml" target="stop"/>
</setup>
<setup name="poitbase">
<start antfile="site-specific/db/pointbase_setup.xml" target="start"/>
<stop antfile="site-specific/db/pointbase_setup.xml" target="stop"/>
</setup>
This example contains one config with name
databases. It has attribute
setup with value
pointbase. There is element
setup with
attribute
name which has also value
pointbase. Element
start
of this
setup will be executed before execution all test of
this config. Second module element with name
db has attribute
setup
with value
oracle. Before execution these tests of db module,
start
element of
oracle setup will be executed. After finishing the
tests,
stop element of
oracle setup will be executed. After
finishing all tests,
stop element of
pointbase setup will
be executed.
Format of site-specific properties
Site-specific properties must have this format:
xtest.userdata(<attrib>)|name=value
or
xtest.userdata|name=value. Only properties which has right
<attrib> and properties without <attrib> will be passed to tests.
To have right <attrib> means that <attrib> contains one attribute
of attributes set for test execution. Part before '|' will be removed for
futher execution.
Example:
xtest.userdata|name1=value1
xtest.userdata(pointbase)|name2=value2
xtest.userdata(stable)|name3=value3
xtest.userdata(unstable)|name4=value4
If tests with attributes e.g. "stable,pointbase" is executed then property
name1, name2 and name3 will be set. Fourth property
hasn't right attribute.
