My latest little project of necessity is Carp::Assert::More.
I've become so spoiled by the swell convenience functions of Test::More that I missed them when I was throwing assertions in code. So, I started a module of 'em.
Down the road, Schwern has asked me to see if I can incorporate them and the rest of Carp::Assert into using Test::Builder, since they're so similar. My first thought is not a good one: Since Test::Builder uses a singleton, I'm not sure that a piece of code that both Carp::Assert and Test::More could co-exist in a single piece of code.
Unless I'm tremendously misunderstanding your point, the Test::Builder singleton exists to make that possible. That's why we wrote it that way. As long as you can translate things into calls to Test::Builder::ok() somehow, it ought to work.
Re:That's the Point!
petdance on 2002-08-10T18:37:19
Here's an example: I've got a module Foo that asserts regularly. Now, I go and run some tests against Foo's functions, including those that assert.but then, I also want to test that, so in mypackage Foo;
sub wango {
my $self = shift;
assert_isa( $self, 'Foo' );
# Now do my object magic
}.t file: In this case, the singleton would be used by (in order) isa, assert_isa and ok. Test::Builder's singletons counts would get screwed up.my $foo = new Foo;
isa( $foo, 'Foo' );
my $n = $foo->wango;
ok( $n, 'wango returned non-zero' );Or maybe I'm the one who's not understanding....
Re:That's the Point!
chromatic on 2002-08-10T19:01:14
Oh, I think I understand. Writing tests for a module that uses Test::Builder can be tricky, yes. That's why there's Test::Builder::Tester.
Re:That's the Point!
petdance on 2002-08-10T21:01:45
Writing tests for a module that uses Test::Builder can be tricky, yes.If we made Carp::Assert use Test::Builder, then EVERY module that uses Carp::Assert (which I hope would be many) would suddenly become one of those tricky modules and people would have to use T::B::T.
:-(
