On Jan 26, 1:41 am, Michael G Schwern <schw...@gmail.com> wrote:
> Sorry, I didn't look around at other interfaces.  I was mostly like
> "OMG the test tester is so SIMPLE now with the event system!  I'll
> implement it and start using it RIGHT NOW!"  I haven't really thought
> it through beyond that.
>
> I'd be *very* happy to have other people drive development of
> TB2::Tester.  Please, I have too much on my plate.  If you tell me
> your github ID I'll give you a commit bit.  You're welcome to break
> the interface so long as you refactor the stuff that uses it along
> with it.

I have pretty much stopped perl dev and have shed maintenance of a
couple of modules so I won't be stepping up to this.

> As for a TB1->TB2 transition plan, the TB2::Tester approach will work
> transparently with Test:: modules written with Test::Builder... as
> soon as I patch up Test::Builder to not be quite so in bed with the
> TAP formatter.  It's the next thing on my plate.

Great,

F

> On Jan 25, 10:48 pm, Fergal Daly <fer...@esatclear.ie> wrote:
>
>
>
>
>
>
>
> > 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 <schw...@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/Buil...
>
> > > 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,

Reply via email to