My Not So Private Tech Life

Have you ever had a Fit(Nesse) test suite of more than just a few pages? Have you ever tried to consistently change the names of test pages, fixtures, columns, commands or anything that is being used a few dozen or a few hundred times across the whole suite? Have you ever wanted to get rid of the 14 setup tables that were copied from your first test page into all others? Have you ever wished you could reorder columns, arguments or parameters in your fixtures?

You get my point. Doing "refactoring" in large FitNesse test collections is a real pain in the neck. I put "refactoring" into quotes, because - strictly speaking - the kind of changes you want to bring about your test pages don't support the definition of the word refactoring:

Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results.

Since we are not dealing with code (one could argue that) and since many changes actually do change the test suite's behaviour, I probably should call it "reorganization". But refactoring sounds way cooler; at least it did in 1999.

Well, to perform these reorganizations your current best choice is to use some regex-based search and replace mechanism and hope that you get the stars, dots, backslashes and question marks right. And even then you never feel sure that you found everything and kept the somewhat weired wiki syntax in place when pressing the "Replace All" button. I haven't seen - and could not find - a tool for FitNesse that tries to tackle these problems. So I went boldly ahead and made my own: ReFit

The long term goal of ReFit is to provide test maintainers with a DSL for refitting (puns++) their tests to the testing language they have in mind and to the code base under test. Currently ReFit is nothing more - and nothing less - than an extended Groovy-Console which provides you with a way to navigate through a FitNesse test suite, change objects of the suite and finally commit all changes back to the file system.

How you go about installing ReFit, starting the console and hooking up to a particular suit is described here. To make your mouth water - or your bowels contract in pain - I'll present a single example script:

suite.pages.findAll { page -> 
    page.name.normalize() == "setup" && 
        page.fixtures.any { 
            it.name.normalize() == "import"
        }
}.each {page ->
    page.fixtures[0].remove()
}

This script will find all "SetUp" pages that also have an "Import" fixture and then remove the first fixture of those pages. What you can guess from it is that one can use all of Groovy's capabilities as a dynamic language to manipulate a straightforward object model of a FitNesse test suite.

This hardly couldn't be further from a real refactoring DSL. I am awaiting the astute users' recommendations to move ReFit further into that directions. And please, if you think that's the wrong path to follow, tell me as well!

It's time again to ditch some dear but no longer needed weight: A couple of month ago I developed ClasspathSuite, a little JUnit4 extension to run test suites which are distributed among several (Eclipse) projects and/or several jar files. At that time I was in need of such a tool and I have enhanced it slightly over the last few months.

Now that JUnit 4.4 is available, some internals of ClasspathSuite do not work any longer, and I just don't find the time to delve sufficiently deep into JUnit 4.4 to make ClassptahSuite do its job.

So, folks, anyone willing to take the project over? Of course, I will provide as much support as I can; the project has some 20 classes including tests. A piece of cake for you, I'm sure.

I put the slides from my session and "power workshop" online. For some weird reason slideshare.net does not want to display one of the presentations - I tried it several times. That's why you find the (German) stuff in two different places:

• Testgetriebenes Ajax (Test-Driven Ajax)
• Fortgeschrittene techniken der testgetriebenen Entwicklung (Advanced TDD)

It is only a first step, though, as far as Test-driven Ajax is concerned. I'm going to put the demo, its sources and all of its automated tests online. Moreover, I'm really and absolutely and fully determined to write a couple of blog entries on the topic. Now or never.

Being on a conference can be fun. Even more so if eventually the time you spent in preparing your workshops and sessions turns out to be well invested.

That's why I feel really sorry for myself that I could not be co-lecturer on monday's power workshop about "Advanced Techniques of Test-Driven Development"; instead I spent the day in a hotel bed trying to cure a flu-like fit of severe headache and fever. So my friend Tammo would have had to cope with the 70 something participants all on his own if Stefan had not come to rescue. Many thanks to both.

However, that day of a good sleep seemed sufficient to make me recover for yesterday's talk on "Test-Driven Ajax". My ex-colleague Marco (andrena objects) and I finished the demo just-in-time and it turned out to be a fine seesion - at least for us speakers. There's a participant's report on the JAX conference blog roll.

As an outcome of all the preparation I plan to cover a few topics in the weeks to come:
- Groovy and testing Java code more dynamically
- Testing and mocking JavaScript
- How to integrate FIT and Selenium

And of course I'll put the slides on slideshare as soon as I'll be back home. Enjoy!

My personal christmas present for you all is version 0.9.5 of ClasspathSuite. You can now include other JUnit4 test suites to be run in multi-project settings in Eclipse.

See this story if you wonder why this is even an issue.

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.