Fixture: Fields and Two Helper Classes
There’s a Map summary that accumulates things like the “run date.” I don’t know why the top-level Fixture has this, but it does. The fixture fit.Summary walks through this table and gives summary statistics.
There’s a field counts that has counts of tests passed, failed, and exceptions/errors. The Counts class is just a data bag for these things. When a fixture calls wrong(), for example, the count is incremented.
The last field is args, which has the arguments from the first row of the fixture. The method getArgs() returns a String[] and lets a fixture use them. I don’t think this is in the C# version yet but we definitely use that sort of thing there.
There’s an internal class RunTime. It takes a snapshot of the current time. Right now, the only use of this is to put it in the summary, under the key “run elapsed time”. Presumably some fixtures pull the RunTime object back out, and use toString() to display the elapsed time. But nothing in the standard distribution appears to use it directly. (Fit.Summary will display the elapsed time when it dumps the summary table.)
Starting Fixtures
Now we come to doTables(), the top-level method. (It’s called by FileRunner, passing in a Parse for each table.) This method first looks at the name in the first cell of the first row of the table. Then it tries to create the fixture, then use it via interpretTables(). Along the way I note that this routine is using a couple null checks; I wonder if those are necessary? If the first table’s fixture fails to be created and run, it runs the remaining fixtures via interpretFollowingTables().
Method getLinkedFixtureWithArgs() tries to load the fixture named in header.text(), then it sets up the arguments (for getArgs().
The method loadFixture() takes the name of the fixture, and attempts to “new up” the named fixture via reflection. Between the last method and this, I’m worried by what I don’t see: what routine uses the camel method? That suggests a test: let’s load “fit.ActionFixture”, “fit.Action Fixture”, and “fit.Action fixture” and see what happens. From what I understood going in, all three should be ok. From what I’m seeing here, I don’t see what would make that work.
Why did I expect this? Because ColumnFixture does it for column names. It turns out that’s not a good enough reason. The test shows that only “fit.ActionFixture” loads.
Up to interpretTables() again. It does getArgsForTable() – again. There’s even a comment to that effect. I don’t see why it should be necessary, though. Actually – it’s all a little subtle, and I’d say the comment is misleading. The comment says, “// get them again for the new fixture object”. But really, that’s what we did in getLinkedFixtureWithArgs(). Now we’re getting the arguments for the original fixture.
It works like this: when FileRunner starts, it runs doTables() on a new Fixture object. That’s the object that tries to pull fixtures from tables and run them. When the first table is seen, its arguments are pulled out and given to the corresponding fixture. But then they’re also copied back to the initial fixture as well. I imagine they’re actually rarely needed there.
At any rate, interpretTables() then calls doTable(), which does a straightforward job of working its way into doCell(). Finally, it calls interpretFollowingTables().
InterpretFollowingTables()
By the time we’re here, we run through a loop, looking up fixtures and then interpreting them with doTable(). For these, we don’t change the arguments on the fixture that started it all. Why not? I can only guess it has to do something with the way DoFixture wants to work – treating the first table special.
All this work seems a little off – it seems the Fixture class is paying for interpretation that a particular table wants. I’m a long way off from looking at DoFixture, but if that’s the table that should be first, it seems to me like it should pay for this complexity. I know I’m second-guessing here…
Check()
The other routines are either straightforward, or I’ve looked at them already. The exception is a largish routine at the bottom: check(). This is a helper method, used by some subclasses. It deals with blank cells, null adapters, “error” expected (to deal with expected exceptions), and text that should match. In each case, this method puts the output in the cell, colored appropriately.
Up next…
I think I want to look into ActionFixture next. I had an unhappy session trying to extend the C# version (which appears to be older). Then I want to dig into how TypeAdapters work.
=====
The series: