Re: Test::Builder2::Tester, first cut

Test::Tester has been doing exactly this for years

http://search.cpan.org/~fdaly/Test-Tester-0.107/

but is very much tied to the Test::Builder guts (by necessity). While
it supports what you have below, the vast majority of the time I just
used the convenience function check_test() which expects you to run
just a single test and combines the capture and comparison steps into
a single call. It also has check_tests but I hardly ever used it. E.g.



I'll happily retire Test::Tester but I would also like to find a way
to keep it working through the migration of Test::Builder to
F

2011/1/25 Michael G Schwern <schwern@pobox.com>:
> I'm happy to announce the first rev of Test::Builder2::Tester.  It lets you
> test Test:: modules without doing string compares on the TAP.  You can test a
> much wider array of detail and much simpler.
> https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
>
> Here's an example testing Test::Simple ok():
>
>    use Test::Simple tests => 2;
>    use Test::Builder2::Tester;
>
>    my $history = capture {
>        ok 2+2==5, "addition";
>        ok 2*2==4, "multiplication";
>    };
>
>    my $results = $history->results;
>
>    result_like $results->[0], {
>        is_pass     => 0,
>        name        => "addition",
>        file        => $0
>    };
>
>    result_like $results->[1], {
>        is_pass     => 1,
>        name        => "multiplication",
>        file        => $0
>    };
>
>    done_testing;
>
> Using Chad's idea, the code being tested is isolated from the rest of the test
> inside a capture() block.  This returns the complete history of whatever
> happened inside its block.  This includes every test event and result, all the
> same information Test::Builder2 uses itself.  result_like() is a convenience
> function which will check only the attributes you specify and ignore the rest.

This looks remarkably similar to Test::Tester :)

Please have a look at its interface (I'm a little surprised that you
seem unaware of it). Almost all uses of it boiled down to a single
function check_test() which was a convenience function which combines
the 2 you have above e  .g.

check_test(
    sub {
      is_mystyle_eq("this", "that", "not eq");
    },
    {
      ok => 0, # expect this to fail
      name => "not eq",
      diag => "Expected: 'this'\nGot: 'that'",
    }
);

which ensures that you ran 1 test in the sub, and then compares the
results to those you've provided. There was also a check_tests() which
expected an array of results and ensured you ran that many tests but
it was almost never used.

> This makes testing a Test:: module much more straight forward and powerful.
> Most importantly, it shields the Test:: module from little changes to the test
> output format.
>
> TB2::Tester is currently a rough proof of concept.  result_like() doesn't
> produce much in the way of useful diagnostics.  results_like() would likely be
> more convenient.  It will eventually work with Test::Builder based modules,
> but they don't work without a TAP formatter just yet.

I would love to retire Test::Tester but it's used by Test:Deep and
some others (and I know it's been used privately too). At the very
least I'd like it to keep working when Test::Builder switches to using
TB2 but it looks a lot like it could become a very thin wrapper around
Test::Builder2::Tester which would be even better,

F

>
> --
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then relied upon it.
>        -- tchrist in <31832.969261130@chthon>
>
>

• Test::Builder2::Tester, first cut by Michael G Schwern
• Re: Test::Builder2::Tester, first cut by Fergal Daly
• Re: Test::Builder2::Tester, first cut by fergal