Agile Performance Testing - Testing Experience

Image5: Output of job “HelloWorld”
Jobs for our tests
In our Hudson set-up, we defined a set of jobs to automatically
execute our tests. These jobs need to be executed on each single
machine, representing a single environment.
The jobs do the following:
• update_svn: revert and update from SVN
• init_server: clean and restart application server
• Install: install software, configure and deploy
• Runtest: setup, run tests, load results into database
• Reg_report_trunk: create report from database
Image6: Overview of jobs
update_svn
This job updates the sources of our test software. All update_svn
jobs get started by one common job - updatesvn_all_trunk, i.e.
the updatesvn_all_trunk job starts jobs update_svn_65_1, update_svn_65_3,
etc. The updatesvn_all_trunk job does not do
anything on its own; it is only responsible to start the children
jobs. The job itself gets started via a remote trigger.
Image7: Remote trigger
With this remote trigger, the job can be started by calling the URL
HUDSON_URL/view/Trunk%20jobs/job/updatesvn_all_trunk/
build?token=TOKEN_NAME.
So any other process, ANT script or other continuous integration
server can trigger the first job on this Hudson server. In our case,
www.testingexperience.com
it is the software build server that starts the Hudson test server.
The update_svn job uses an ANT script to clean, revert local
changes and get updates from SVN. We already had these ANT
SVN targets in place, and therefore did not use Hudson’s internal
SVN integration. Our SVN jobs start ant target svn-all, with
parameters svn.user=$SVNUSER and svn.password=$SVNPWD.
These $-values represent variables, and will also be available on
the node as environment variables. Variables can also be set during
execution (as parameterized builds), on the level of a job, on
the level of a node, or as a global parameter. As our svn.user and
password are the same on all nodes; we used a global parameters
for this, which you can define under main configure menu, and
they are therefore valid for all nodes and all jobs.
Alternatively, Hudson also
provides SVN integration. It
requires that SVN executable
is available on the remote
node, and authentication is
working on that node. Inside
the job you will then need to
define the SVN URL. The first
time Hudson will check out
under the remote directory /
, and once checked
out, it will do updates on this
directory. When you have multiple jobs on the same node, Hudson
would create separate SVN working directories for each job.
To avoid this, you can use symbolic links to have one single physical
directory only.
The Magazine for Professional Testers
29