Test::Builder2::Tester

[schwernbot]

From: @schwern Date: Wednesday Jan 19, 2011 at 00:12 GMT Orig: https://github.com/Test-More/test-more/issues/112

The event system provides a solution to the Test::Builder::Tester problem. Right now, if you write a Test module and want to test it, you either have to capture the TAP output and do string comparisons on it. Test::Builder::Tester only mitigates the problem, it does not make it go away. As a result, even the simplest changes to the TAP format cause tests to fail. Test::Class is failing with TB2 largely because I changed "# skip" to "# SKIP" to make it consistent and more obvious that it's a directive.

Test::Builder2::Tester would take a completely different approach. Rather than capturing and comparing the TAP, it captures and compares the test events directly.

It might look like this example testing Test::More's is() and like() (once it's been transferred to TB2).

my @results = capture {
    like "thing", qr/thing/;
    is "this", "that", "a name";
};

result_is( $results[1], {
    file    => __FILE__,
    line    => __LINE__ - 5,
    pass    => 0,
    name    => "a name",
    diagnostics => {
        have    => "this",
        want    => "that",
    },
});

capture would...

• make a new event coordinator with no formatter, just history
• store a copy of the EC singleton
• make the new EC the singleton
• executes the code block, their events going to the new EC
• reinstate the original EC singleton
• return the results from their own history

This lets you test anything in isolated chunks with all the magic encapsulated. It lets you use the module being tested to test itself.

Test::More's responsibility is to produce a valid result, so that's all it has have to test. It trusts that the formatter will do the right thing with that result. If there is reason not to trust the formatter, it can unit test it directly because it's a separate object. See the tests in t/Formatter for examples.

[1] The capturing is already done by a Test::Builder2::History object.

[schwernbot]

From: @exodist Date: Wednesday Jan 19, 2011 at 16:28 GMT Orig: https://github.com/Test-More/test-more/issues/112#issuecomment-690189

The older more complex Fennec solved this a different way:

my @results = capture {
    ok( 1, "Some Test" );
    is( 1, 1, "universe is sane");
};

where capture had a block prototype capture(&)

capture() itself would replace the collector that was responsible for sending results to the main process. In TB's case capture would replace the event coordinator, run the code, grqab the results, restore the coordinator, return the results.

Once that is done creating results_are {} [...], "name"; and similar is trivial, and they are consistant with Test::Warn and Test::Exception as far as API style go.

[schwernbot]

From: @schwern Date: Saturday Jan 22, 2011 at 03:25 GMT Orig: https://github.com/Test-More/test-more/issues/112#issuecomment-698019

Oooh, that's much simpler! I like it. I've updated the ticket to reflect that plan.

[schwernbot]

From: @schwern Date: Tuesday Jan 25, 2011 at 04:16 GMT Orig: https://github.com/Test-More/test-more/issues/112#issuecomment-704983

Implement result_like() and event_like() for TB2::Tester

Closed by de7e90d2fe5c57841587630704bc0be7102f2d8c

[schwernbot]

From: @schwern Date: Tuesday Jan 25, 2011 at 04:18 GMT Orig: https://github.com/Test-More/test-more/issues/112#issuecomment-704985

capture() works as desired. result_like() and event_like() are very basic. They don't issue any diagnostics. Writing it revealed limitations in how the Result object is architected, namely that you can't change it's state. It would be very useful to start with a passing result object, accumulate diagnostics on it, and set it to fail as necessary.

I'll open a new ticket to work on the TB2::Tester diagnostics.