My Not So Private Tech Life

XP Day Germany in Hamburg is over. I was quite nervous about it since it does not happen too often that I'm being invited to give a keynote on any topic I like. So I sat back and reminisced about my former life as an Extreme Programming enthusiast.

Don't get me wrong: I still do think that XP is the underestimated jewel among the better known agile methodologies. During recent years, however, my enthusiasm was replaced by a feeling along the line "XP is too good for this world". Sometimes the "too good" felt more like "too difficult for most organizations and teams". I felt this kind of disillusionment to be rather wide-spread - at least within the German community, of which many members are meanwhile content to be mere "agilists" instead of "extremos".

So I tried to put all whining aside and concentrate on how to bring passion back into Extreme Programming. My points were basically threefold:

• XP has to change because the world of software is changing at light speed. Technological explosion and the inevitable advance of multi-site development are just two indicators for that fact.
• As XP practitioners we have to concentrate on the human (and humane) side of system building to be successful. We must become the cream of the crop of change agents.
• Let's restart to be extreme. Just saying what we think is right won't be enough, we have to live up to our beliefs.

In short, I don't think it's enough to be agile. You can listen to the full talk and see the slides on this screencast. Be warned: it's in German and sound quality is not as good as it should be.

Stefan Roock made me aware of the fact that Eclipse (3.2) does not have support for JUnit testing in a multi project setting. He points to some code by Björn Martensson which tackles the problem by searching the classpath for test classes. However, the code works for JUnit 3.8 only, so I set up to tackle the problem for JUnit 4.1.

I tried to come up with a JUnit4-like solution, i.e. using the RunWith annotation. You can download my JUnit extension here.

The mechanism is simple. Just create a new project in Eclipse and add all projects that contain tests you want to run to its build path. Now create a class like that:

import org.junit.extensions.cpsuite.ClasspathSuite;
import org.junit.runner.RunWith;
@RunWith(ClasspathSuite.class)
public class MySuite {}

This will execute all JUnit4 testclasses (those containing methods with the @Test annotation) in the projects classpath. By default jar files are being ignored but you can include them in the search for tests by adding another annotation:

import org.junit.extensions.cpsuite.ClasspathSuite.*;
...
@IncludeJars(true)
public class MySuite...

And you don't have to run all tests. Instead you can use another annotation to restrict the tests to run by regex expressions which will be applied onto the class name before adding a test class to the suite:

import org.junit.extensions.cpsuite.ClasspathSuite.*;
...
@ClassnameFilters({"mytests.*", ".*Test"})
public class MySuite...

The filter patterns work disjunctively; if any one filter matches, the class will be added to the suite of tests.

P.S.: ClasspathSuite solves another problem (bug?) in the JUnit 4 integration of Eclipse 3.2: test classes derived from an abstract test class which do not have test methods of their own are being ignored by Eclipse's test runner. When using RunWith(ClasspathSuite.class) you will catch those test classes as well.

Today, I stumbled across Slideshare, a website for publishing and sharing your presentations. I'm still not sure if giving all of my material away is a good thing, but I experimented and uploaded the slides of a lecture I'll be giving tomorrow at the University of Applied Sciences in Heilbronn.



The slides are all in German, but as far as this blog is concerned it's not the content that counts but the chosen means to share it with you.