The answer to my coloring quandary in a previous problem turns out to have been solved reasonably easily.

I started looking at checkResult to see what was around and I saw that I had access to the TestResults class. Victory! Just do this:

    if(matches == true) {
        testResults.pass();
    } else {
        testResults.fail();
    }

DONE!

Well, not quite. Turns out that tells the test runner that you have the correct number of passes, but your cells remain uncolored. Happily, CalledMethodTargetStandard had some fairly simple code that I could co-opt.

    if (result instanceof String) {                                            
        expectedCell.failWithStringEquals(testResults,valueParser.show(result),runtime);
    } else {
        expectedCell.fail(testResults,valueParser.show(result),runtime);
    }

That’s actually kind of transparent, given the struggles I had in my previous efforts. All you have to do is tell the cell to fail. I question the idea of telling an element that seemingly corresponds to a UI element to fail when you have an interface called TestResults in context, but that’s not my call to make, and I’m not planning to rewrite anything to make sense of it.

The answer for me, then, was to set up this lovely block:

    if (price.matches(Double.valueOf(arg1.toString())))
    {	
        arg0.pass(arg4);
        return true;
    } else {
        arg0.fail(arg4, arg1.toString(), runtime);
        return false;
    }

where arg0 is my Cell, arg4 is my TestResults, and arg1 is my Object value from the combine method.

It’s still hacky. But it really does seem to work now, at least for reasonably simple tests.