Archive

Posts Tagged ‘FitNesse’

Creating a Fitnesse Wiki Widget

April 2, 2009 Comments off
Fitnesse

Fitnesse

We are using Fitnesse to acceptance test our REST apis.  One of our calls requires that a UUID be created and then used in several places throughout the test.  The syntax we wanted to use was :-

!define myUUID ${!uuid}

This however is not possible, because the !define widget in fitnesse does not support value interpolation.  So, we hit on a revised syntax which looks like this:-

!uuid{myUUID}

This assigns a randomly generated UUID to the variable myUUID, which is then referencable by the usual fitnesse wiki syntax ${myUUID}.  The implementation looks like this:-

import java.util.UUID;
import java.util.regex.Pattern;
import java.util.regex.Matcher;

import fitnesse.wikitext.widgets.ParentWidget;
import fitnesse.html.HtmlUtil;

public class GuidWidget extends ParentWidget {

public static final String REGEXP = “!uuid\\{[\\w]+\\}”;
private static final Pattern pattern = Pattern.compile(“!uuid\\{([\\w]+)\\}”);

private String varName;

public GuidWidget(ParentWidget parent, String text) throws Exception {
super(parent);
final Matcher matcher = pattern.matcher(text);
matcher.find();
varName = matcher.group(1);
}

public String render() throws Exception {
this.parent.addVariable(varName, UUID.randomUUID().toString());
return HtmlUtil.metaText(varName + ” assigned a UUID”);
}

public String asWikiText() throws Exception {
return “!uuid{” + varName + “}”;
}
}

When researching how to implement my own custom widget, I read several posts complaining that !define myVar {!MyWidget(thing)} does not evaluate the custom widget in the define widget.  Well, the ParentWidget class, which you have to extend, allows you to call parent.addVariable(varName, varValue) which does the magic for you.
The one slightly tricky part was that you need to register your widget in the plugins.properties file, and then make sure the new class is in the classpath of fitnesse (not your tests via the !path property).  To do that, all you need to do is add the compiled class to a jar, put the jar in your fitnesse runner lib directory, then amend the run.bat or run.sh.  Our new run.bat looks like this:-

java -cp fitnesse.jar;lib\guid.jar fitnesse.FitNesse ....
pause

When fitnesse starts, it reads all the widgets in the plugins.properties WikiWidgets property and loads them.  It then outputs a list of the widgets that it has added to the console out.

By: Chris Tarttelin

User Stories and Such

March 10, 2009 1 comment

StoryI have been attending sessions and tutorials from the Agile track at SD West for the most part. I am interested in learning about how the experts recommend we write user stories, acceptance tests, AMDD and Agile estimation and planning. This post is about the ‘From Stories to Automated Acceptance Tests’ session by Brett Schuchert. Here are some recommendations I have gathered:

  • We need acceptance tests in the stories to let the devs know when they are ‘done’.  We already do this, and our devs are usually good about pointing out when acceptance tests are incomplete or vague.
  • Acceptance tests should be run on a staging machine before we mark the story as complete.
  • Acceptance tests should not be technology specific. “Click the OK button” implies there is an OK button, which is a web design call, not a BA call. Instead the BA should state the acceptance criteria to be “The user indicates he is done”
  • An acceptance test should have a few assertions. Many assertions in an acceptance test is an indication that the story needs to be be split up.
  • Too much mocking can lead to integration failures.
  • User stories should be specific, concrete rather than an abstraction. Examples may be provided to illustrate the point. A good story should not be vague, should not be time bound (some event that might occur in the future is an example of this – this is not testable), should be specific and not too broad.
  • Include stories of conflict or error that we would like to handle.
  • Remember INVEST and SMART

Acceptance test automation: There is a lot of talk at the conference about FitNesse and Slim. I saw some examples of these being used for acceptance tests. Since FitNesse is wiki based, we can add text or images to describe what the purpose of the tests are. This additional information is ignored by FitNesse. Also, the FitNesse configs should not be machine specific (should not include reference to paths, etc.)

By: Veena Mankidy