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 wrote:
Option three.
isa_ok
if( has_pod( $file ) ) {
pod_ok($file, POD_OK);
}
Test::Pod is getting rewritten to use Pod::Simple instead of
Pod::Checker. All the "mode" flags that are passed to pod_ok() will be
deprecated. Also, pod_ok() itself will be deprecated, in favor of
pod_file_ok() and pod_string_o
I'm writing a test which does basic checks on all the code in a repository.
It checks that all scripts and modules compile without warnings. I also
want to check that all the POD has no errors or warnings. However, a
lot of the code has no POD. I don't want to write all the POD right now,
but I
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. Al
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. Allows you to do
> things like:
>
> output_is { hello() } "hello world\n", STDOUT, "hello world";
> outp
On Fri, Feb 28, 2003 at 11:51:07AM +, Adrian Howard wrote:
> Option three.
>
>isa_ok($obj, 'MyClass');
>is_deeply($obj, { foo => 42, bar => 23 });
This is, unfortunately, shallow. It won't compare objects inside $obj.
On Friday 28 February 2003 12:23, Adrian Howard wrote:
> Comments:
>
> - I'd prefer is_set rather than is_math_set
So would I but eq_set is already taken by Test::More and I want to name the
is_ and the eq_ functions conistently
> - I'd like shallow comparison options as well as deep one
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
On Thu, Feb 27, 2003 at 10:03:50PM +, Fergal Daly wrote:
> > > - let _deep_check take it's cue from the second argument. If the second
> > > argument is blessed then be strict about the classes, if it's unblessed
> > > then ignore the classes. This should happen at all levels in the
> > > stru
On Thu, Feb 27, 2003 at 09:21:09PM +, Fergal Daly wrote:
> > I am already not yet convinced. In particular, it makes this sort of test
> > more difficult than it needs be:
> >
> > is_deeply($obj, { foo => 42, bar => 23 });
>
> Absolutely, but there is currently no way to do this
>
> is_d
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 in general), I reckon in the context of
> test suites it's a bug.
I am already not yet convinced. In particular, it mak
14 matches
Mail list logo
