For example:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.resolveFile("ram://root/file.txt").createFile(); // prepare test harness
...
manager.resolveFile("ram://root/file.txt").getName(); // do something useful

Annoyingly, Apache VFS API provides a way to check if a file/folder is hidden, but, although it is always possible to manually create hidden files on your system, there is no way to mark a file as hidden in the RAM filesystem.

manager.resolveFile("ram://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram://root/.file.txt").isHidden(); // also returns false

The solution is to modify the RAM filesystem and customize its checking of the hidden attribute. This means that we need a new RamFileProvider, a new RamFileSystem and finally a new RamFileObject. In this example, all files and folders whose names start with a dot will be considered hidden:

public class RamFileProvider extends org.apache.commons.vfs2.provider.ram.RamFileProvider {
  @Override
  protected FileSystem doCreateFileSystem(FileName name, FileSystemOptions fileSystemOptions) throws FileSystemException {
    return new RamFileSystem(name, fileSystemOptions);
  }

  private static class RamFileSystem extends org.apache.commons.vfs2.provider.ram.RamFileSystem {
    public RamFileSystem(FileName rootName, FileSystemOptions fileSystemOptions) {
      super(rootName, fileSystemOptions);
    }

    @Override
    protected FileObject createFile(AbstractFileName name) throws Exception {
      return new RamFileObject(name, this);
    }
  }

  private static class RamFileObject extends org.apache.commons.vfs2.provider.ram.RamFileObject {
    public RamFileObject(AbstractFileName name, RamFileSystem ramFileSystemWithHiddenSupport) {
      super(name, ramFileSystemWithHiddenSupport);
    }

    @Override
    public boolean isHidden() throws FileSystemException {
      // this is the important part
      if (getName().getBaseName().startsWith(".")) {
        return true;
      }
      return super.isHidden(); // in practice, this always return false
    }
  }
}

Finally, this new RamFileProvider must be registered with your existing FileSystemManager. In my case, I get something like that:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.addProvider("ram-ext", new RamFileProvider());
manager.resolveFile("ram-ext:///root/file.txt").createFile();
manager.resolveFile("ram-ext:///root/.file.txt").createFile();
...
manager.resolveFile("ram-ext://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram-ext://root/.file.txt").isHidden(); // returns true

Note that I did not replace the “ram” filesystem entirely. Although that would have been my preferred option, that would have taken too much time in my little experiment.

In general, when I test classes that have dependencies, my favorite approach is to pass those dependencies to the constructor:

public class MyService {
	private final MyDependency myDependency;

	public MyService(MyDependency myDependency) {
		this.myDependency = myDependency;
	}
}

Which makes creating test harnesses with Mockito reasonably easy:

public class MyServiceTest extends UnitTest {
	@Test
	public void shouldComputeAResult() {
		MyDependency mockMyDependency = mock(MyDependency.class);
		when(mockMyDependency.findSomeValue()).thenReturn("some value");

		MyService service = new MyService(mockMyDependency);

		assertThat(service.computeSomething(), equalTo("result"));
	}
}

However, it appears that Guice, at least under version 1.1.1 of its Play module, can only be used with Play to inject into static members:

@InjectSupport
public class MyService {
	@Inject
	static MyDependency myDependency;
	// no constructor (a default constructor will be
	// generated automatically by Play Framework)
}

The @InjectSupport is what makes the Guice module detect that the class requires dependencies (a class that extends either com.google.inject.AbstractModule or play.modules.guice.GuiceSupport must also be present in the classpath).

This makes it hard to instrument classes under test, as the value for a mock instance of MyDependency is shared amongst all tests that run currently.

public class MyServiceTest extends UnitTest {
	@Test
	public void shouldComputeAResult() {
		MyDependency mockMyDependency = mock(MyDependency.class);
		when(mockMyDependency.findSomeValue()).thenReturn("some value");

		MyService service = new MyService();
		// static values are brittle;
		// they should not be touched in unit tests
		service.myDependency = mockMyDependency; // yuck!

		assertThat(service.computeSomething(), equalTo("result"));
	}
}

Many subtle problems may occur when injecting dependencies in this way. For example, all instances of MyServices used concurrently will point to the same dependencies instances, so it is possible that tests will behave in inconsistent ways. Also, it makes it harder to default to sensible (null) dependencies, since tests running in the same JVM will by default use dependencies set by the first test.

The solution I’m using is to add providers in your Guice module:

public class GuicyModule extends AbstractModule {
	@Override
	public void configure() {
		// no code needed
	}

	@Provides
	public MyService getMyService(MyDependency myDependency) {
		return new MyService(myDependency);
	}
}

In this way, you are making sure that the dependencies are passed as you wish. Also, it will not be necessary to add any sort of Guice-related code in my services:

public class MyService {
	private final MyDependency myDependency;

	public MyService(MyDependency myDependency) {
		this.myDependency = myDependency;
	}
}

The downside is that you do have a few more lines to maintain, which is never fun. Better than the alternative, though.

My thanks to David Gageot who told me about providers in Guice.

“Going nowhere fast” by Nathan

The session on Faster Tests (led by David) was interesting, at least to the extend that it was quite clear that we at Algodeal are not doing too bad indeed (Douglas Squirrel from youDevise is another one that seems to be quite cerebral about tests and builds).

By looking that the various options discussed to get tests faster, I think it’s fair to say that the only way to really speed up tests is by compromising their integrity, at least to a level. In a way, to make tests faster, you’ve got to face reality and move away from their ideal abstraction (very reminiscent of Joel Spolsky’s Law of Leaky Abstractions). The only question is: how confident are you that those (slightly compromised) tests actually test something useful?

This leads to the conclusion that we only keep long integration tests because it is difficult for us to really understand what’s going on. If we did have an excellent understanding, we would have unit tests instead. And, interestingly, as we progress in our project, we find ways to convert integration tests into unit tests. In other words, we better understand what’s going on.

Also, check out my notes on the session on Mock Objects.

• Java Power Tools – getting it all together by John Smart, 
• Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams, by Darryl Bowler, 
• Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level, by Craig Smith and Paul King,
• CI vendor cage-fight! by Tom Sulston: in this one, various tools vendors, will demonstrate their CI server — I might do the Hudson one

OK, I do prefer Hudson (I am a contributor, after all). But I also watch the competition… err, I mean, like the other tools ;-) Here are other presentations I could find that mention competitors to Hudson:

• (CruiseControl) Agile Source Code Management using Stories, Agile Workflow, and CI,by Damon Poole
• (CruiseControl) Creating Habitable Code: Lessons in Longevity from CruiseControl, by Jeffrey Fredrick and Paul Julius
• (CruiseControl) Build Engineer Bootcamp: Builds As Code, by Jeffrey Fredrick and Paul Julius: though not explicitly about CruiseControl, the hosts are the main contributors to CruiseControl, so expect to hear about it!
• (CruiseControl) Continuous Integration: Your New Best Friend, by Howard Deiner
• (Bamboo) Automated deployment with Maven and friends – going the whole nine yards, by John Smart: though it does mention Hudson, the focus will be on Bamboo
• (Bamboo) Large scale continuous integration, by Hannu Kokko: the session outlines does not explicitly says so, but it seems that Bamboo is part of the toolset

It was kicked off by an interview of Ward Cunningham and James Shore on Hanselminutes where Ward & James were asked whether Fit was dead.

Bob Martin first reacted on Twitter by pointing out that, at any rate, “FitNesse is thriving”, along with Slim, a new system that can be used by Fitnesse as an engine to run the test tables.

Michael Feathers replied that, in his view, Fit was more appropriate as a seed for other works: “Take it, grow it locally, and never commit back.” This seems confirmed by James Shore, a former leader of the Fit project (and a successor to Ward in that role): “Fit core was intentionally resistant to change [...] from an organizational perspective”

Interestingly, James believes that both Fit and Fitnesse have “similar flaws, which could be solved by another approach”:

• “Fit flaw #1: maintenance. HTML is hard to maintain and refactor.”
• “Fit flaw #2: Customers. Customers don’t generate the documents, and that was the whole idea.”
• “Fit flaw #3: Programmers. Fit loves domain models and Whole Value. Most programmers don’t. Impedance mismatch.”

This last point is actually seen as a benefit by J.B. Rainberger: “Similar to JUnit, Fit puts positive pressure on programmers. [That said] TDD informs design, but many use JUnit for testing. Fit informs feature design, but many use Fit for testing.” James agrees: “Fit drives the design of the domain layer just as TDD drives separation of concerns.”

JB & James both note that, regardless of the tool itself, they “continue to succeed collaborating with customers with Fit’s table format”, typically by “collaborating with examples on a whiteboard”.

Possibly, the biggest shortcoming (as stated by James & Ward during the interview, but also in twitter by Brian Marick: “I can’t offhand think of any product owner who wrote tests in any format”) is that the assumption that business people would write the tables was flawed. A view not shared by Keith Braithwaite “I’ve had actual users write tests in tables in excel with success”. JB, for one, prefers “Customers help write docs”, reformulated by Elisabeth Hendrickson as “Business stakeholders & implementation team collaborate on articulating expectations.”

Finally, several people including Willem van den Ende pointed to BDD and especially to Cucumber as a better implementation of the same ideas “Cucumber given/when/then steps flow naturally for me, FIT- style tables are optional, I add them later if needed.”

For more details see the following links:

• Details by James Shore on how to use Fit (or not)
• Michael Feathers’ opinion on the code that makes the Java implementation of Fit
• The interview of Ward Cunningham and James Shore on Hanselminutes

In the release he did a couple of days ago, he added 2 interesting things:

• one is a format tool that helps giving a more readable view of your tables, in editing mode; unfortunately, your edit panel must be using a fixed-size font (which it is not the case by default on my system)
• the most interesting addition, though, is the support of SCM tools to store wiki pages

There are two ways to configure a SCM tool.

The first is to specify it on the command line:

  java -DCM_SYSTEM=package.to.AParticularCmSystemIntegrationClass -jar fitnesse.jar

The second is to specify in a high-level page on your hierarchy of pages:

  !define CM_SYSTEM {com.project.fitnesse.OurSvnSystem me/my_password /cm/myRespository}

This one is interesting, because it allows you to have different configurations for different hierarchies of pages (typically one for each different projects, or even for different versions of the same project).

The bad news, though, is that the CM System Integration class in question is not provided by default, though I’m sure that in time there will be all sorts of appropriate integration classes provided with Fitnesse. But that’s not the case so far (except for an example made to connect to Git — not sure how generic it is). That said, it does seem quite easy to implement that class (you basically need to implement calls to the command line in Java).

You might want to download the Fitnesse release and check out the FitNesse.UserGuide.SourceCodeControl page. As often with Fitnesse, the website does not have the latest details.

I think I have finally fixed (most) errors in the display of the French translation in Hudson. 3 different people reported them to me, which is a sign that Hudson enjoys a strong following in France (I also keep stumbling on French Hudson fans in conferences and my colleague Eric Le Merdy has just released a new Hudson plugin for Nabaztag).

The root of the problem is that I incorrectly thought that properties should be encoded in UTF-8 (in fact, only help pages in HTML should be). In practice, properties files should stay in classic ISO 8859-1.

I didn’t keep trace of which files I had incorrectly converted to UTF-8 and I don’t know of a tool that could check that for me (if you know of one, do let me know). So there is still a chance that some files remain in the incorrect format. If you find any, please create a bug report.

The fix should be available with the next release of Hudson, v.1.269, which should be a matter of days, according to history. My progress on the French translation are listed on the Hudson wiki.

Apologies to all that were inconvenienced by this bug.

Not content with the videos on Slim, he has just produced another one showing how to do basic staff with Hudson. And by the sound of his voice, he is sold!

Inteerstingly, he compares the simple startup process of Hudson to the one in Fitnesse: just download and run.

Update (14/12/08): Uncle Bob has actually put online his Hudson install

Data types in Slim are simple. They can only be Strings and Lists, though it is entirely possible for fixtures to actually get integers.

A list looks like this:

[1, 2, 0.5]

Note the brackets. Also, note the space between the comas and the following value. This is important, as the comparaison will actually be made between the exact string specified in the table, and the String representation of the List returned by the fixture. Hence, the format in toString() is important.

There are two majors things to learn in it:

• approximate equals
• ranges

The ~= sign means “approximately equals to”, and depends on the number of decimals; for example,

~=1.3

in a cell will work for any value between 1.2 and 1.4.

A range allows Slim to accept results between boundaries. For example, put something like

1<_<8

in a cell and all values between 1 and 8 will be considered valid. This is something that some versions of Fit could do, but not all. With Slim, all versions of Slim will support this (since it will be evaluated on the Fitnesse side).

Last thing: Fitnesse contains a rather powerful expression evaluator that is not specific to Slim or Fit.
For example:

!define TIMES {1000}
|${=5*${TIMES}=}|

You can combine this construct with the range, and have something like this in your cell:

${=5*${TIMES}=}<_<${=6*${TIMES}=}

which will appear as

5000<_<6000

when viewing your wiki page.

Finally, you might want to watch out for the coming minor release of Fitnesse.