Fully automated Web Application Testing with Selenium and Hudson

Lately i have been setting up a fully autometd Web Application Test environment. I just wanted to share my experiences!

My application has a number of selenium tests that i wanted to run on our continious integration server (hudson). My current scenario includes the following steps:
  1. Start the Selenium-RC server from Hudson
  2. Compile the application and the test cases
  3. Reinitialization of the database via DBUnit
  4. Starting the Tomcat - application server
  5. Running the Selenium test cases
  6. Publish the test results in Hudson

Start the Selenium-RC server on Hudson
The Selenium RC server is started from Hudson at the beginning of each build as a shell call.


As you can see in the picture this step is done before i trigger an ant script which includes all the following steps. Therefore it is imperative that a user is logged on to the DISPLAY =: 0.

The full command is here (As you can see, i also specified the path to a logfile):
DISPLAY=:0 java -jar ${WORKSPACE}/ecm.server/lib/test/selenium/selenium-server.jar -log ${WORKSPACE}/ecm.server/selenium.log &



Compile the application of the test cases by Ant +

The first step that is triggered from the ant script is a full build of the webapplication and the selenium test cases.

Reinitialization of the database from Ant via DBUnit

The next step is a full reset of the database used by the application with a initial set of data. Using DBUnit this can be done very easy. I just made an export from an initial dataset which is written to the database every build. Here you can see the ant target which does the job.

   

Starting the Tomcat - application server from Hudson

I also setup a dedicated tomcat on the build machine used for the selenium testcases. It is started from the Ant script in the next step. You can see the ant script here, note that ant is waiting until tomcat is started up by checking if the webport of tomcat is online.




Running the Selenium test cases from Hudson, by Ant

the Selenium tests are also run from Antwith the following ant script:


As you can see at first i delete the old test results. After that the tests are run via the testng ant task using ReportNG to generate some nice looking test results.


Publish the test results in Hudson

After the tests are run i use two hudson Post-build Actions to publish the test results.




The first is Archive the artifacts:
This Actions archives all resources of the specified folder from the last build. Thiese are the generated TestResults which provide some nice looking results.

In order to get statistics of all test cases ever run i also use the Action Publish JUnit test result report, which uses the Junit xml Resultfiles and generates statisics.

The result can be seen in the hudson project page. There you see an overview of the test statisics.



By clicking on the archived "index.html" you can display the reportng testresult:


Cheers

ScalaModules slides from W-JAX 09 online

There were a lot of interesting talks at the OSGi Day at W-JAX. If you are interested in the slides of my ScalaModules talk you can take it from here: http://www.slideshare.net/heiko.seeberger/wjax-09-scalamodules

Lift slides from W-JAX 09 online

The Scala Day at W-JAX was a great success: Many cool talks and lots of interested folks. If you are interested in the slides of my Lift talk you can take it from here: http://www.slideshare.net/heiko.seeberger/wjax-09-lift

Scala 2.8: Be more concise with named and default arguments

Scala 2.8 will bring quite a lot of interesting new features, e.g. redesigned collection libraries, named and default arguments, support for continuations, a pimped REPL, etc. In the following I will show how named and default arguments enable us to write our Scala code even more concisely than before.

Let's flesh out an example in the 2.7 style: An order with an ID, order items and a shipping mode.

case class Order27(id: Long,
items: List[Item],
mode: ShippingMode)

case class Item()

sealed trait ShippingMode
case object StandardShipping extends ShippingMode
case object ExpressShipping extends ShippingMode
case object OvernightShipping extends ShippingMode

The order's ID shall be "mandatory" while we want to allow for defaults for the item list and the shipping mode. Hence we have to provide some auxiliary constructors.

case class Order27(id: Long,
items: List[Item],
mode: ShippingMode) {

def this(id: Long, items: List[Item]) =
this(id, items, StandardShipping)

def this(id: Long, mode: ShippingMode) =
this(id, Nil, StandardShipping)

def this(id: Long) =
this(id, Nil, StandardShipping)
}

As you can see, now it is possible to create an order by only giving the ID, e.g.

val order = Order27(1)

will create an order with the items set to the empty list (OK, this does not make too much sense in practice) and the shipping mode set to standard shipping.

On the one hand that's nice. But on the other hand the code is blown up significantly and it will take the reader some time to reason about the different possibilities to create an order, what is mandatory and what is optional with defaults.

Scala 2.8 let's us define default values with the class (or method) parameters by simply putting the default values behind the type.

case class Order28(id: Long,
items: List[Item] = Nil,
mode: ShippingMode = StandardShipping)

Now we can leave out the arguments for which defaults are defined, e.g.

val order = Order28(1)

will again create an order with no items and standard shipping. But this time there is no auxiliary constructor necessary to achieve that. Wow!

But how can we give the shipping mode and leave out the items? Looking at the order of the parameters in the primary constructor it is obvious that we have to give the item list before the shipping mode.

val order = Order28(1, HERE GOES THE ITEM LIST, OvernightShipping)

This is where named arguments enter the game. We simply prepend an argument value with its name, e.g.

val order = Order28(1, mode = OvernightShipping)

This way Scala knows how to get things right. Wow!!

Invitation to improve ScalaModules’s DSL

Over the last months the ScalaModules team has worked on the upcoming 2.0 release. There will be a lot of improvements, e.g. auto-registration of service interfaces, operator notation, filters as objects and the user guide transferred to the Wiki. We are not ready for a final release yet, but most things should already be fairly stable.

There is still one thing we are racking our brains over a lot and maybe one of you could come up with a better solution that we have got right now. The new API for registering services offers auto-registration of service interfaces, such that there is no need to explicitly define the service interface(s). The following snippet will register the service greeting under the service interface Greeting, because greeting implements Greeting.

trait Greeting ...
val greeting = ...
ctx register greeting

Of course there are times when you want to explicitly register a service under a certain service interface. Now it would be very nice to write something like

ctx register greeting as classOf[AnotherInterface]

But this will not work in the current implementation, because register will be executed before as, which will register greeting under Greeting, just like above. Hence you have to use parenthesis like

ctx register (greeting as classOf[AnotherInterface])

Of course we have come up with a nice operator notation which takes the neccessary precedence into account. You could register greeting under the service interface AnotherInterface like this

ctx < greeting / classOf[AnotherInterface]

There is no need to use parenthesis here, because / will be executed first, because its precedence is higher than <.

But we would still like to get rid of the parenthesis in the "wordy" style. Roman already came up with an idea which you can take from the ScalaModules Google group. But when it comes to using as and withProps at the same time this is not adequate. So the question is, whether you have an idea how we could write something like

ctx register as classOf[AnotherInterface] withProps ("x" -> "y")

I am looking forward for your suggestions!

OSGi-fied Scala libraries updated to 2.7.6

Now that we have got Scala 2.7.6 I also updated the OSGi version of the Scala libraries. Please take it from the scala-tools.org Maven repository.

Currently there is an ongoing discussion about modularizing the official Scala code base, just take a look at the scala-internals mailing list. Hopefully we will see some success soon which might make the extra OSGi version obsolete though. But right now these extra OSGi-fied libraries are the way to go if you want to run OSGi on Scala or Scala on OSGi.

Eclipse Insurance Day 30.9.09 in Köln

EIDNach den Erfolgen der Eclipse Banking Days veranstaltet WW nun eine Fachkonferenz zu Open Source-basierten Lösungen für Versicherungen. Der technologische Schwerpunkt liegt auf Eclipse, allerdings richtet sich die Veranstaltung primär an IT-Entscheider aus Versicherungen und IT-Dienstleistern für Versicherungen. Redner sind u.a. Mike Milinkovich, Excutive Director der Eclipse Foundation sowie Prof. Dr. Helten, Präsident des Bayerischen Finanz Zentrums
(-> Agenda).

Die Resonanz auf die ersten Ankündigungen ist hervorragend, so dass ich mich auf einen gut besuchten Tag mit spannenden Vorträgen und Gesprächen am Rand freue.

Zur EID Anmeldung

OSGi on Scala slides from OSGi DevCon Europe 09 online

In my former blog post I reasoned about whether I should do a live demo of OSGi on Scala / ScalaModules at OSGi DevCon Europe 09. As I received very positive feedback from the community (thanx for that!) I decided to go for it. Now I just finished my short talk and everything (at least the hacking part) went fine. For those not able to attend, please find the slides (which try to give you some live feeling) at my Slidespace.

Running OSGi and ScalaModules in Scala’s REPL

Next Monday I will talk about OSGi on Scala at OSGi DevCon Europe 09. As I have already given this talk twice (OSGi DevCon 09 and JAX 09), I am currently searching for some kind of fresh and cool style. Sitting in a very lonely German town I have come up with a crazy idea: Why not do the (short) talk using Scala's REPL (the interactive Scala console) instead of slides? To be honest, I am not yet sure whether to go this way, but my trials were very facinating and hence I would like to share my experiences with you.

OK, one step back. What exactly am I talking about? Well, fairly simple: Run the Scala REPL, launch OSGi (Felix, because it is very easy to launch/embed) to get a BundleContext (of the system bundle) and do some ScalaModules tricks to show the power of this DSL for OSGi.

In order to have Felix and ScalaModules on the classpath we have to copy felix.jar (currently using 1.8.0), scalamodules-core-1.1-SNAPSHOT.jar and scalamodules-util-1.1-SNAPSHOT.jar to a local directory and run Scala like this:

scala -cp felix.jar:scalamodules-core-1.1-SNAPSHOT.jar:scalamodules-util-1.1-SNAPSHOT.jar
scala>

First let's import some important stuff:

scala> import org.apache.felix.framework._
import org.apache.felix.framework._

scala> import org.scalamodules.core.RichBundleContext._
import org.scalamodules.core.RichBundleContext._

Then let's create and start Felix and get the BundleContext (which subsequently will be implicitly converted into a RichBundleContext):

scala> val felix = new Felix(null)
felix: org.apache.felix.framework.Felix = org.apache.felix.framework [0]

scala> felix.start

scala> val ctx = felix.getBundleContext
ctx: org.osgi.framework.BundleContext = org.apache.felix.framework.BundleContextImpl@e0c389

Then let's create a service interface:

scala> trait Greeting { def hello: String }
defined trait Greeting

Now let's use ScalaModules to (try to) get a Greeting service and use it. If you are experienced in OSGi you will know that for this task you would have to get a ServiceReference, check for null, get the service, check for null again and finally unget the ServiceReference again => Fairly low-level and involved. Now look at ScalaModules:

scala> ctx getOne classOf[Greeting] andApply { _.hello } match {
| case Some(s) => println(s)
| case None => println("No Greeting service available!")
| }
No Greeting service available!

OK, now let's register a Greeting service:

scala> val greeting = new Greeting { def hello = "Hello" }
greeting: java.lang.Object with Greeting = $anon$1@6159e9

scala> ctx registers classOf[String] theService greeting
:13: error: type mismatch;
found : java.lang.Object with Greeting
required: String
ctx registerAs classOf[String] theService greeting
^

As you can see, service registration with ScalaModules is type-safe at compile time. Hence let's do it right now and try to use it once more:

scala> ctx registerAs classOf[Greeting] theService greeting
res4: org.osgi.framework.ServiceRegistration = ...

scala> ctx getOne classOf[Greeting] andApply { _.hello } match {
| case Some(s) => println(s)
| case None => println("No Greeting service available!")
| }
Hello

There a lot of other things we could do the easy way using ScalaModules instead of OSGi API. I will show some more of these at my talk at OSGi DevCon Europe 2009, but first I have to decide whether using REPL for the talk is a good idea. What do you think?

OSGi-fied Scala libraries updated to 2.7.5

Some days ago Scala 2.7.5 was released and today I updated the OSGi version of the Scala libraries (see my former blog), too. I received some (positive) early feedback, but I am still very interested in knowing about any kind of real-world "production" usage.

Currently I am using these libraries in an effort to add OSGi support to Lift. This is very challenging, not only because of too little time, but also because Lift still has to work without OSGi. Well, hopefully I can get some basic OSGi support ready for Lift 1.1.