On Sat, 15 Dec 2001 02:41:13 -0500
Barrie Slaymaker <[EMAIL PROTECTED]> wrote:
> > IMHO Test::Differences' benefit is its mix-in nature. Changing
> > each is_deeply() to eq_or_diff_data() hand by hand "if not ok"
> > seems a little hassle to me.
>
> Why is it more effort than doing something li
On Sat, Dec 15, 2001 at 06:52:40PM +0900, Tatsuhiko Miyagawa wrote:
> Again, IMHO we can get the benefit of Test::Differences like this:
>
> * First, test the code with Test::More::is()
>
> is $complicated_long_text, $expected;
>
> * but it fails.
>
> Test::More's output is too long for me t
On Sat, 15 Dec 2001 05:26:01 -0500
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Why not just use Test::Differences's function in the first place?
Two cases for using Test::*
1) Testing our application (for paying work)
it's good to use T::D in the first place.
2) Testing my CPAN module
I d
Now I see what you're after with the -M approach, thanks for the
example.
On Sat, Dec 15, 2001 at 07:54:17PM +0900, Tatsuhiko Miyagawa wrote:
> Two cases for using Test::*
>
> 1) Testing our application (for paying work)
>
> it's good to use T::D in the first place.
We're agreed here :).
> 2
On Sat, Dec 15, 2001 at 01:56:19AM -0500, Michael G Schwern wrote:
> On Sat, Dec 15, 2001 at 02:41:13AM -0500, Barrie Slaymaker wrote:
> > There's also a test script for the escaping now :). I'd love to test
> > characters for codepoints > 0xff, but they're borken / unsupported in
> > all release
On Sat, Dec 15, 2001 at 07:54:17PM +0900, Tatsuhiko Miyagawa wrote:
> 2) Testing my CPAN module
>
> I don't like letting go Test::More for it ;)
If I understand you, they work together fine.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance
On Sat, 15 Dec 2001 07:10:33 -0700, Barrie Slaymaker wrote:
> How about having Test::More use eq_or_diff_data() in is_deeply() if it cane
> eval "use Test::Differences;" and use it's current routine if it can't? That's
> as seamless as you can get.
Wild idea:
How about splitting out the
On Sat, Dec 15, 2001 at 10:52:07AM -0700, chromatic wrote:
> On Sat, 15 Dec 2001 07:10:33 -0700, Barrie Slaymaker wrote:
>
> > How about having Test::More use eq_or_diff_data() in is_deeply() if it cane
> > eval "use Test::Differences;" and use it's current routine if it can't? That's
> > as seam
> On Sat, 15 Dec 2001 13:18:23 -0500, Michael G Schwern <[EMAIL PROTECTED]> said:
MGS> On Sat, Dec 15, 2001 at 10:52:07AM -0700, chromatic wrote:
>> Wild idea:
>>
>> How about splitting out the error-reporting, with a nice default in
>> Test::Builder or wherever, using optional modules if po
On Sat, Dec 15, 2001 at 01:18:23PM -0500, Michael G Schwern wrote:
> On Sat, Dec 15, 2001 at 10:52:07AM -0700, chromatic wrote:
> > On Sat, 15 Dec 2001 07:10:33 -0700, Barrie Slaymaker wrote:
> >
> > > How about having Test::More use eq_or_diff_data() in is_deeply() if it cane
> > > eval "use Tes
On Fri, Dec 14, 2001 at 05:20:24PM -0700, chromatic wrote:
> On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote:
>
> > ExtUtils::MM_Cygwin
>
> Here's a test for that. It could use someone on Cygwin testing it. Tels said
> he would, but apparently got busy.
Thanks, applied.
--
$jhi+
The bad news is perlcc is completely shot, and has been since 5.6.1.
The bytecode and Perl->C compiler is completely busted and nobody's
stepped forward to fix it. The last people to do so was Simon Cozens
and tchrist. Simon's busy with Parrot and Tom's gotten a life outside
Perl now. Malcolm B
Ok, here's what I've decided.
The is_ok() thing will be cmp_ok(). Best name I could think of.
The current behavior of is() wrt undef, 0 and '' being considered
different will remain. I've decided is() is its own thing and the small
bit of magical behavior is Good.
unlike() and diag() will be
On Sat, Dec 15, 2001 at 11:46:29PM +, Nicholas Clark wrote:
> On Sat, Dec 15, 2001 at 05:59:22PM -0500, Michael G Schwern wrote:
> > On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> > > Te"One day Math::Big* will have more tests than Perl;)"ls
> >
> > One day Perl will have more tests
On Sat, Dec 15, 2001 at 02:19:21PM -0800, Kurt D. Starsinic wrote:
> On Dec 15, Dave Rolsky wrote:
> > Ok, so that's a bit off the topic of "why use isa_ok()" but I just don't
> > see why people seem to object to the use of Test::More in the core Perl
> > tests. I can't see how it couldn't help i
On Sat, Dec 15, 2001 at 11:46:29PM +, Nicholas Clark wrote:
> On Sat, Dec 15, 2001 at 05:59:22PM -0500, Michael G Schwern wrote:
> > On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> > > Te"One day Math::Big* will have more tests than Perl;)"ls
> >
> > One day Perl will have more tests
On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> Te"One day Math::Big* will have more tests than Perl;)"ls
One day Perl will have more tests than Bit::Vector. 67255 at last count.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 15-Dec-01 Jarkko Hietaniemi tried to scribble about:
>> Ok, so that's a bit off the topic of "why use isa_ok()" but I just don't
>> see why people seem to object to the use of Test::More in the core Perl
>> tests. I can't see how it couldn't help impr
On Dec 14, Michael Schwern wrote:
> Constructors fail often enough that I felt it worthwhile to write a
> test function for them.
>
> You could leave off the test entirely and just trust that you use $foo
> later on down in the test and it'll explode there, but its better to
> put the point of fa
On Sat, 15 Dec 2001, Kurt D. Starsinic wrote:
> > my $foo = Foo->new;
> > ok( defined $foo && $foo->isa('Foo') );
> >
> > which rapidly gets tiresome.
>
> Or ok(UNIVERSAL::isa(Foo->new, 'Foo'));
Under 5.005 it spits out warnings if Foo->new returns undef. Plus you
still don't get an
On Dec 15, Dave Rolsky wrote:
> Ok, so that's a bit off the topic of "why use isa_ok()" but I just don't
> see why people seem to object to the use of Test::More in the core Perl
> tests. I can't see how it couldn't help improve the quality of the tests
> while providing a standardized way to do
> Ok, so that's a bit off the topic of "why use isa_ok()" but I just don't
> see why people seem to object to the use of Test::More in the core Perl
> tests. I can't see how it couldn't help improve the quality of the tests
> while providing a standardized way to do the things that all the tests
The second [1] Test::Harness 2.00 release candidate just went up to CPAN
http://www.pobox.com/~schwern/src/Test-Harness-2.00_04.tar.gz
As Test::Harness is a rather critical module, and this release is a
fairly major reshaping of the internal code, I'm going to do a round
of release candidates so
Thinks like use_ok, require_ok, isa_ok, can_ok, etc... are all
functions that I threw into Test::More because I found myself needing
them and suspected others did, too. If you prefer to use ok() instead
of one of the above special purpose functions, I'm not going to jump
up and down and fling poo
Forgot to mention, there are a few user visable interface changes to
Test::Harness::Straps in 2.00_03 (and thus _04) that have changed
since 2.00_01.
* 'summary' is now 'details'. It wasn't much of a summary.
* Test #1 is now element 0 on the details array. It works out better
th
Kurt mentioned he'd like more verbose information about how the tests
are progressing as it happens, rather than having to wait until the
end. In the perl core, the normal 'make test' doesn't give you much
information at all because it has to use a neutered harness.
I just remembered, you can ru
This passes all tests, gets the MANIFEST patch right for once, and shouldn't
have weird sorting bugs on EBCDIC platforms. Cross your fingers.
-- c
--- ~MANIFEST Sat Dec 15 23:17:25 2001
+++ MANIFESTSat Dec 15 23:17:42 2001
@@ -906,6 +906,7 @@
lib/ExtUtils/inst Give informati
Here are tests for everything but the 'debug' subpragma of the re pragma.
That'll take a bit more scary regex-fu than I have at the moment. Anyone who
is daring enough to change re.pm, re.xs, or re.c, though, now has no excuse for
improving the tests.
-- c
--- ~MANIFEST Sat Dec 15 23:53:50 20
Chromatic wrote:
[snip]
> +re->unimport('taint');
> +isnt( $^H & 0x0010, 1, 'unimport should clear bits in $^H when requested' );
> +re->unimport('eval');
> +isnt( $^H & 0x0020, 1, '... and again' );
These tests are wrong. $^H & 0x0010 will never be one, no matter
what is in $^H. It
On Sun, 16 Dec 2001 00:43:07 -0700, Benjamin Goldberg wrote:
> chromatic wrote:
>> +re->unimport('taint');
>> +isnt( $^H & 0x0010, 1, 'unimport should clear bits in $^H when
>> requested' ); +re->unimport('eval');
>> +isnt( $^H & 0x0020, 1, '... and again' );
> These tests are wrong.
30 matches
Mail list logo
