True. I usually expose "deep" objects by methods rather than hash
access, so it's not really a problem for the majority of my code.
Adrian
On Friday, February 28, 2003, at 03:54 pm, [EMAIL PROTECTED] wrote:
On Fri, Feb 28, 2003 at 11:51:07AM +, Adrian Howard wrot
Jeez! These people with free time :-) ;-)
On Friday, February 28, 2003, at 04:00 pm, [EMAIL PROTECTED] wrote:
On Fri, Feb 28, 2003 at 11:40:52AM +, Adrian Howard wrote:
I always meant to revisit the idea for Test::Output which was intended
to be a generic FILEHANDLE output testing module
Nice.
Comments:
- I'd prefer is_set rather than is_math_set
- I'd like shallow comparison options as well as deep ones. Most of the
time I'm interested in object identity rather than structural equality.
Maybe have: is_bag, is_set, is_deep_bag, is_deep_set
- I'm not sure that ignoring duplica
On Thursday, February 27, 2003, at 09:21 pm, Fergal Daly wrote:
On Thursday 27 February 2003 20:54, [EMAIL PROTECTED] wrote:
On Thu, Feb 27, 2003 at 05:32:42PM +, Fergal Daly wrote:
I think that although a test that ignores blessed classes could be
handy
in some circumstances (ie programming
I'd go for feature, not bug. For me is_deeply has always been for
testing structure. We have isa_ok for checking class identity.
Having one that tested for both might be useful, but I would not change
the behaviour of is_deeply.
Adrian
On Thursday, February 27, 2003, at 05:32 pm, Fergal Daly
I'd argue that Test::Warn isn't the right place :-) To me sending
output to STDERR and warnings are different things.
If added to Test::Warn I'd argue for separate functions. I've had
situations where warnings were logged, and STDERR was meant for user
readable output. Having them merged would
Ah. Confusion of vocab. You're talking about the order of the test
scripts rather than the order of tests run by those scripts. Yes?
I think Tony was talking about the order of tests.
While key test scripts tend to be run earlier in some setups, I'm not
sure that's it going to be a useful disti
On Wednesday, November 13, 2002, at 08:54 pm, Michael G Schwern wrote:
[snip]
I think I'll merge your $Test::Builder::default idea with this. Have a
stack of Test::Builder objects rather than just the states. This way you
can do something like the above. If you add a $tb->copy method which
ret
On Wednesday, November 13, 2002, at 08:37 pm, Michael G Schwern wrote:
On Tue, Nov 12, 2002 at 04:21:38PM +, Adrian Howard wrote:
At YAPC::Europe there was some discussion about Test::Builder->level,
$Test::Builder::Level and the fact that they don't really work well as
impleme
On Monday, November 11, 2002, at 04:10 am, Michael G Schwern wrote:
At YAPC::Europe there was some discussion about Test::Builder->level,
$Test::Builder::Level and the fact that they don't really work well as
implemented. I know we reached some sort of consensus about how to do it
better, but
On Tuesday, November 12, 2002, at 01:40 am, Michael G Schwern wrote:
On Tue, Nov 12, 2002 at 01:31:43AM +, Mark Fowler wrote:
Test::Builder->new would remain as a singleton. We'd just provide an
alternate constructor to provide a second object if someone really wants
it.
You know, that
On Saturday, October 26, 2002, at 04:22 pm, Nicholas Clark wrote:
[snip]
However, I'd like to be able to cleanly print out my random number seed to
STDERR (or whatever Test::Builder's correct name for this is) if it
believes
that any tests have failed, and I can't see a clean way to do this.
Whe
Hi all,
There's been a new version of Test::Class coming 'real soon' for a few
months now :-)
Amongst the bug fixes and extensions I've been considering a couple of
changes that I'm not 100% on and would appreciate any comments /
feedback / abuse on offer... it's late so apologies if this makes
Hi all,
On Thursday, October 10, 2002, at 05:04 pm, Tony Bowden wrote:
[snip]
> use Test::Class;
> use UNIVERSAL::require;
>
> my @tests = qw( Example::Test Another::Test );
> foreach my $class (@tests) {
> $class->require or die "Can't require $class";
> }
> Test::Class-
@;
};
};
Test::Class->runtests( @TEST_CLASSES );
Can you pass on the version # of Attribute::Handlers & UNIVERSAL::require
you're using - since it's failing silently for me, rather than giving the
error... will investigate further.
Adrian
--
Adrian Howard <[EMAIL PROTECTED]>
phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
On Monday, August 26, 2002, at 08:22 am, Michael G Schwern wrote:
> On Mon, Aug 26, 2002 at 12:48:45AM +0100, Adrian Howard wrote:
>> I've added a patch to Test::Exception (should have spotted that...
>> *bad*
>> Adrian :-). It should be hitting CPAN in the next few
On Saturday, August 24, 2002, at 11:08 pm, chromatic wrote:
> I've been using Test::Exception on a project and am very glad to have
> it. I
> ran into a small issue trying to install it, though: it has TODO tests,
> but
> those failed as the existing version of Test::Harness (1.26 or so) did
On Saturday, August 3, 2002, at 09:56 pm, Andy Lester wrote:
> I'm adding some tests to Test::HTML::Lint, and one of the things that I
> want to check for is that "html_ok(undef)" fails. Remember that
> html_ok() is a T::B-based module.
[snip]
Take a look at Test::Builder::Tester. Something li
On Monday, July 1, 2002, at 03:21 pm, Janek Schleicher wrote:
> Hello!
>
> On Sun, 30 Jun 2002, Adrian Howard wrote:
>
>> Nothing like it AFAIK - sounds useful. I've got places where I'm doing
>> this sort of thing, but I slurp up STDERR rather than wrapping
&
Oops... forgot to CC to group. Adrian.
Begin forwarded message:
> From: Adrian Howard <[EMAIL PROTECTED]>
> Date: Sun Jun 16, 2002 08:25:37 pm Europe/London
> To: Michael G Schwern <[EMAIL PROTECTED]>
> Subject: Re: Test::Class... comments?
>
> On Sunday, June 1
neatest solution to the inheritance problem mentioned
in the documentation. How offensive do people find this, and is there
a better solution?
The obvious alternative (you supply the package of the method you want
to affect) makes refactoring harder since you have to remember to
update the package
On Sunday, June 9, 2002, at 02:59 am, chromatic wrote:
> On Saturday 08 June 2002 17:32, Adrian Howard wrote:
>
>> I eventually just bit the bullet and started writing more functional
>> tests. This (of course) had the usual affect of writing more tests ---
>> it
o swap mock/live objects
by subclassing and/or configuration options.
Once I started writing decent functional tests, my hack to track changed
methods suddenly ceased being useful. I think you may find the same
thing occurring with Test::Depend - it will just encourage you to write
more functional tests ;-)
Cheers,
Adrian
--
Adrian Howard <[EMAIL PROTECTED]>
phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
est_args) succeeded";
is_deeply(\@results, $test_results,
"method(@$test_args) = (@$test_results)");
};
The sequence of tests was stateless --- one test failing didn't invalidate
the other test cases. Running them all rather than exiting the test script
after a sing
on 10/4/02 11:10 pm, Michael G Schwern at [EMAIL PROTECTED] wrote:
> On Wed, Apr 10, 2002 at 10:57:09PM +0100, Adrian Howard wrote:
>> Hmmm... All seems sensible. Patch attached for Builder.pm that adds a
>> _may_be_regex method. Okay?
>
> Except it should be public (if Tes
d, Apr 10, 2002 at 11:03:27AM +0100, Mark Fowler wrote:
>> On Tue, 9 Apr 2002, Adrian Howard wrote:
>>
>>> Any comments before I throw it at CPAN? Sound vaguely sane?
>>
>> throws_ok can take either a class name or a Regexp ref as an argument to
>> compare again
on 9/4/02 10:16 pm, Michael G Schwern at [EMAIL PROTECTED] wrote:
[snip]
> You probably want to guarantee that $@ will be how it died so you can do:
>
> dies_ok { div(1,0) } 'div by zero';
> like( $@, qr/^Illegal division by zero/ );
>
> Even though you can use throws_ok(), the dies_ok() + $@ co
Hi all,
I've been refactoring a bunch of old tests with Test::More and some
convenience routines for testing exceptions dropped out (along with some
class base testing and mock object modules which still need cleaning up into
something sane.)
dies_ok BLOCK TEST_NAME
Tests to see that
Hi,
Newbie with Test::More --- and loving it :-)
on 10/12/01 12:04 pm, Michael G Schwern at [EMAIL PROTECTED] wrote:
> Its been on the Test::More todo list to have a blessed way to do:
>
> print STDOUT "# here's some extra info\n";
>
> I'm planning on using diag().
>
> ok( $foo == $bar ) ||
29 matches
Mail list logo
