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

Current situation

As a pre-build test, I am trying to verify that any commits / changes to java devices will not break any suitability tests I have on my fitness server.

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

I currently have a HashMap "class name" for "class object" for all available java tools available. I was also able to access all fitness exams as File objects. It looks something like this:

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

      

purpose

Now I want to do something like this:

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

      

Then I would just compare the two HashMaps and make sure the parsedMethodsFromFitnesseMap HashMap is a subset of the available JavaClassesMap HashMap model.

Care

  • Include files: how to handle the parsing of these first / other approaches.
  • Scenarios: Create your own list of known scenarios and how they work.

The perfect solution

  • Is there a parser already made that will do this?
    • I found Slim Code and I think it can be refactored for my needs.
  • Is this the best approach for this pre-build validation?

Note

Each test is very expensive to run, so just running all tests to make sure they still work is not an option for my needs.

Ideas? Thank.

+3


source to share


1 answer


My decision

The approach I ended up with was using SVNKit to programmatically output from svn to the system temp folder and then did my parsing and method comparison and then deleted the directory when I was done.

For runtime, if I pulled and parsed 200 tests, it took about 20 seconds. However, about 90% of the time is spent simply pulling tests from the svn repository.

By holding the repo instead of deleting it, it will solve this timing problem (besides the first pull explicitly), however for my jUnit style approach, I will probably take longer damage to encapsulation.

I made sure that the imports were parsed before distribution so that the scripts in them could be used in analyzing the actual tests.



I ended up not using any fine code (however, if you want to do this, the InstructionExecutor class was what I thought was the most useful / closest to the parser.

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

Note

I've never tried a calm approach that could give faster execution times, but I liked the simplicity once the repo was successfully pulled onto the machine.

0


source







All Articles