Use Slim to Parse Fitnesse Test Context.txt File in Java

Question

Current Situation

As a pre-build test, I am trying to check that any commits/changes to java fixtures will not break any fitnesse tests I have in my fitnesse server.

The approach I have taken is to grab all the tests (context.txt) files that I want to verify the commit will not break, and parse it the best I can and compare it with the available methods I can grab using reflection from my projects.

Currently, I have a HashMap of 'class name' to 'class object' for all my available java fixtures. I also have been able to get access to all the fitnesse tests as File objects. It looks a little like this:

HashMap<String, Class<?>> availableJavaClassesMap = initJavaMap();
List<File> allFitnesseTestFiles = initTestFiles();

Goal

Now I want to be able to do something like this:

HashMap<String, Method> parsedMethodsFromFitnesseMap;
For(File file: allFitnesseTestFiles) {
    parsedMethodsFromFitnesseMap.addAll( parseFile( file ) );
}

Then I would simply compare the two HashMaps and make sure the parsedMethodsFromFitnesseMap HashMap is a subset of the availableJavaClassesMap HashMap.

Worries

• Include files: how to handle parsing those first/other approaches
• Scenarios: create my own list of known scenarios and how they work

Ideal Solution

1. Is there an already made parser that will do this?
   • I have found the Slim Code and think it could be refactored to my needs.
2. Is this the best approach for this pre-build check?

Note

Each test is very expensive to run, therefore simply running all the tests to see if they still work is not an option for my needs.

Ideas? Thanks.

Answer 1

My Solution

The approach I settled on was using SVNKit to programmatically pull from svn into the systems temp folder and then did my parsing and comparing between methods and then deleted the directory when I was done.

For execution time, if I pulled and parsed 200 tests, it took about 20 seconds to do so. However, about 90% of the time is taken up by simply pulling the tests from the svn repo.

Holding on to the repo instead of deleting it would solve this timing issue (besides the first pull obviously), however for my jUnit style approach, I will probably take the longer time hit for sake of encapsulation.

I made sure that the import files were parsed before hand so that the scenarios in those could be used when parsing the actual tests.

I ended up not using any of the slim code (However if you want to give it a shot, the InstructionExecutor class was what I thought was most useful/close to a parser.

This was a fairly easy approach and I would recommend it.

Note

I never tried the restful approach, which might of yielded a faster execution time, but I did enjoy the simplicity once the repo was successfully pulled onto the machine.