To enable this feature, override the default test listener in the JUnitHelper instance you use for test runs (third constructor argument), and supply a JUnitXMLTestListener instance passing the folder where you want the XML files in the constructor argument. For example:

 String htmlOutputDir=new File(System.getProperty("java.io.tmpdir"),
                                  "fitnesse").getAbsolutePath();
  String xmlOutputDir=new File(System.getProperty("java.io.tmpdir"),
                                   "fitnesse-xml").getAbsolutePath();
  String fitNesseRootDir=".";
  JUnitXMLTestListener xmlTestListener=new JUnitXMLTestListener(xmlOutputDir);
  JUnitHelper helper =
      new JUnitHelper(fitNesseRootDir,htmlOutputDir,xmlTestListener);
    helper.assertTestPasses(".....");
 

Grab the source from my github repository. Also, check out the full example.

This three day workshop immerses the participants into a project driven by Specification by Example and Agile Acceptance Testing. Through facilitated exercises and discussion, you will learn how to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop and deliver systems fit for purpose.

This workshop is aimed at testers, business analysts and developers. It combines an introduction to Specification by Example and Agile Acceptance Testing, a set of exercises to help you get started with FitNesse – the most popular tool for agile acceptance testing – and a full day of working on realistic domain examples taken from your recent projects or a future phases of projects. This ensures that you gain real-world experience, enabling you to kick-start internal adoption of these practices in your team.

Click here for more information and to register.

What’s new in this version?

Since the book was originally released, both FitNesse and the .NET FIT test runner were improved significantly. All the examples in this book are now updated to be compatible with the latest releases of FitNesse (20091121) and FitSharp (1.4). I re-wrote parts that are no longer applicable to the new FitSharp test runner, especially around Cell Operators. In a classic example of self-inflicted scope creep, I also wrote a new chapter on using domain objects directly.

I also changed the tool used for assembling the book. Instead of Apache FOP, I used XEP which will hopefully make the layout a bit better. Fonts (especially the code font) were also changed to make the book easier to read.

What about the paperback

I will make the paperback available soon. At the moment, the second edition is only available online.

“We get what we measure”, said he, adding that the system is going to game the metrics. “Does finding a lot of bugs really mean that you have good testers, or does it mean that you have crap code?”, asked North. He also mentioned several examples of how people game the system in software development, including commenting out failing tests to increase test pass rates and generating tests without assertions to increase test coverage. Improving the efficiency in these parts leads to inefficiencies on the global level. “When you focus on efficiency of a part, you lose sight of the big picture. [...] Efficiency is the enemy of effectiveness.”, said North.

Likewise, things that seem very inefficient can produce great effect on the global scale. As some examples of that, North mentioned cross-functional teams, pair programming, parallel spikes and the theory of constraints. Using a less controversial topic, he said that experimentation and innovation are very inefficient if considered on their own because they lead to lots of work that will necessarily be thrown away, but the global results of that are very effective.

North suggested that teams shouldn’t care about effort, but about the effect. Functional points, velocity, man hours and similar are easy to game and can lead to local optimisations that hurt the big picture. It is crucial to measure the correct thing and North suggests measuring cycle time for end-to-end customer satisfaction or cost of the end-to-end process, including opportunity costs and factoring in time.

So how can we improve the effectiveness? North suggests these pointers:

• Understand that you’re working in a system, and that it is likely that there is a system above that system and a system above that one
• Identify the goal of that system – sometimes it’s just its own survival
• Step outside to observe the effects – how well does its goal align with yours?
• Think about what’s stopping the system from giving you what you want, and improve that.

I’ll be posting many more articles on Oredev in the next few days. Subscribe to my rss reed to get notified about updates