Fit Reading (part 3 of 8) – Parse and Fixture

Posted on by

Parse

First I want to chase down a couple oddities in what I saw last time. It boils down to these two tests:

// This test shows offset isn't applied the way I expected
public void testOffset() throws Exception {
    int offsetToData = 2;
    Parse p = new Parse(
        "xxdata", Parse.tags, 0, offsetToData); 
    assertEquals("", p.leader);
}

and:

// This test shows cells with embedded tables "go away"
public void testInnerTables() throws Exception {
    Parse p1 = new Parse(
        "stuff plus");
    Parse p2 = new Parse("stuff" + "inner plus");

    Parse cell = p1.at(0,0,0);
    assertFalse(cell.body.equals(""));
    assertEquals("stuff plus", cell.text());

    cell = p2.at(0,0,0);
    assertFalse(cell.body.equals(""));
    assertEquals("stuff inner plus", cell.text());
}

(I sent email to the maintainers; these may just be demonstrating my ignorance of how it’s intended to work.)

FixtureTest

It won’t take long to look at this: it only has one test!

    assertEquals("     ", Fixture.escape("     "));

The method basically handles converting plain text to have HTML entities.

But there’s a little more going on in Fixture…

Fixture

I’ve only got a few minutes, so this is a quick overview. From the FileRunner, I can see that doTables() is an important entry point. Last time I looked in the Java version, it was simpler than it is now. There are comments showing code added for DoFixture and for fitnesse, and they’ve made it all a little trickier. This is all to make an improvement at the user level.

The core of this is: doTables() calls getLinkedFixtureWithArgs() and interpretTables(), which (eventually) calls doTable(), which calls doRows(), which calls doRow() once for each row, which calls doCells(), which calls doCell() once for each cell. In Fixture, doCell() calls ignore(), which marks the cell gray. ColumnFixture(), for example, overrides doCell() to do something interesting (like look for expected results).

I’m going to skip over how the first table gets loaded and interpreted – it looks interesting (i.e., tricky:) Instead, I’ll peek down to a section labeled “Annotation”. This area contains methods that can mark and color cells: right(), wrong(), info(), ignore(), error(), and exception(). I’ve seen these called in several of the standard fixtures before.

I see where exception() puts the stack trace into the cell. That gets SO ugly when something goes wrong. (It makes the cell huge, full of scary content useful only to programmers.) Maybe someday I’ll take a whack at a more readable version.

Utilities

The final section is Utilities. The lightly tested escape() method is there. There’s also a method to put words into camel case. I’ll add a test:

assertEquals("twoWords", Fixture.camel("two words")); assertEquals("MiXedCAsE", Fixture.camel("MiXed cAsE")); assertEquals("aFewWordsTogether", Fixture.camel("aFewWordsTogether")); assertEquals(     "acronymsLikeHTMLStillUppercase",      Fixture.camel("acronyms like HTML still uppercase"));

Hmm. This is perhaps not the pattern I’d have chosen. I have the impression some of the other languages do it differently.

There’s a parse() method that appears to handle only Strings, Dates, and ScientificDoubles. I know that C# works a little differently, since parse() is more integrated.

There’s a check() method that looks too complicated to understand in 30 seconds. It uses a TypeAdapter, which is another class I want to look at soon.

Finally, there’s a method to get the arguments from a Fixture. This is new – it used to be that the first row had the fixture only. (Rather, you had to parse any arguments out yourself.) Now that’s built in, accessed via getArgs(), which returns a String array.

That’s it for today. Next time, I want to dig into how fixtures get started (since this has changed some), and into the check() method.

=====
The series: