Agile Performance Testing - Testing Experience

In this article we describe how Hudson, a continuous integration
server, helped us to achieve a next level of test automation, where
we start tests on several machines from one central console.
Test execution before using Hudson
In our department we have a big collection of unit test cases. For
each build that we test, we run these test cases on multiple environments:
multiple application servers, multiple databases and
multiple configurations. We have a set of Virtual Machines (VMs),
all with their own specific configuration, and on each individual
VM execute the same set of tests. Although we used ANT to automate
our execution steps on a single machine, we still spent a lot
of time connecting up all machines:
• copying the new build to a central network location
• on each machine: updating unit tests from the SVN repository
• on each machine: starting ANT to install the new build, configuring
the unit client environment, deploying software on
the application server
• on each machine: starting the application server, setting up
the initial database, running tests, loading test results into
the database
• after execution has finished, generating a report with all test
results.
Most of these steps are the same for each VM, and need to be repeated
for each new build. So getting this automated promised a
lot of potential time saving.
Introducing Hudson
Next comes Hudson, a continuous integration tool written in
Java, It supports SCM tools including CVS, Subversion, Git and
Clearcase and can execute Apache Ant and Apache Maven based
projects, as well as arbitrary shell scripts and Windows batch
commands. Continuous integration servers are especially strong
in distributing tasks over multiple machines. There is one central
console that dispatches tasks to all nodes, and thus binds jobs
together. In our company we also have experience with Teamcity
and Bamboo, which are both licensed. We then came across
Hudson, which is an open-source solution. The good thing about
Hudson is that it has a very active community, and many additional
plug-ins have been released, extending it from purely being
a build tool for Java projects. New builds come out every week.
We have set up Hudson on two different networks, and so far we
© iStockphoto.com/petesaloutos
Using Hudson to run junit regression tests
on multiple machines
by Manik Thakur & Jan Kester
are very content. Below we will describe one of our set-ups, which
runs in any servlet container.
Installation
On the Hudson website, http://Hudson-ci.org/, you can download
the latest war, and either start this with Java -jar, or drop it in your
favourite servlet container. When you run it from the command
line, you can add some simple arguments to add basic security:
java -jar Hudson.war –argumentsRealm.passwd.
admin=donttell \
--argumentsRealm.roles.admin=admin --http-
Port=8001 --prefix=/Hudson
Now you can open a browser at http://localhost:8001/Hudson/,
and log in with admin/donttell.
Image 1: Welcome Page of Hudson
Alternatively, Hudson can be installed as a Windows service. Under
Manage Hudson, there is a link which will configure Hudson
as a Windows service under the installed directory provided.
Configuration
Under manage Hudson -> Configure System, we configured
global settings and paths, which were commonly used by all the
nodes (VMs). On the main page you can change settings for:
• Smtp mail server: Of course, you will want this, as sending
mail is essential for a continuous integration server.
• Security settings: We only used simple security to have one
single admin.
• Default behavior for source code repositories.
26 The Magazine for Professional Testers www.testingexperience.com