schwern wrote in perl.qa :
>
> Degenerative cases aside, a very good test of actual code anyone would
> use in production in real life for a Perl parsing attempt is
> Test::More (since it has a few odd constructs and a good test suite),
Good advice. Test::More actually helped me to find bugs in
Vlad Harchev wrote:
> I'm testing some perl source code transformation tool (kinda perl source
> code prettifier). I would like to test
> it by running over some huge software package written in perl that have
> testsuites written for it available (i.e. I would like to transform some
> package's so
Mark Fowler <[EMAIL PROTECTED]> wrote:
> > > I'd like to have a custom version of is(), say binary_is(), that
> > > reports 'strings 1 and 2 differ at byte 635, got 0x92, expected 0x42'
> > > or 'strings 1 differ in length, got 3874, expected 3875'.
>
> Oooh, that would be really helpful. I often
Hi, here's an easy question for you Test:: experts :
I write lots of test those days with is() comparing binary
strings (mainly produced by combination of pack() and other
algorithms.) The problem is that the output message of is()
when those tests fail is not very helpful.
I'd like to have a cus
Paul Johnson <[EMAIL PROTECTED]> wrote:
> I thought the solution might be more complex than it turned out to be,
> and so I included a patch to the test suite to add a TODO test using
> fresh_perl_is().
>
> Rafael was quite rightly concerned about this. When the bug is fixed we
> don't want unne
[EMAIL PROTECTED] wrote:
> For a more fine-grained view, you
> need hooks into Perl internals (such as the Perl malloc).
This sounds like Devel::Peek::mstat(). But I never looked at this before.
alian <[EMAIL PROTECTED]> wrote:
> > * searchable for the past (and for keywords in failures or fulltext, like
> > "bigint"
>
> Yep I will add this shortly.
>
> > * spares me the "smoke foo" messages, that contain all Ok and fool me into
> > thinking there was some smoke
>
> Sorry my so poor en
Tels wrote in perl.qa :
>
>> Well, B::SPECIAL is for one of the internal constants '0', '1' and
>> 'undef'. There ought to be a better interface to this, but I can't
>> really figure out what to improve.
>
> I have no idea what you talk about - I am a total B:: newbie :)
The big story :
Each
Tels wrote in perl.qa :
> --- Cover.pm.old Wed Sep 4 23:36:14 2002
> +++ Cover.pm Wed Sep 4 23:38:46 2002
> @@ -144,6 +144,8 @@ sub report
>
> for my $sub (@Todo)
> {
> +next unless $sub->[1]->CV->isa('B::CV');
That's a guard against a B::SPECIAL object, isn't it ?
We
Michael G Schwern wrote:
>>I keep forgetting that I need to remember to ask this. Is there a FAQ
>>for regression test writing? Well, an guide to "so I want to write a
>>regression test, explaining how to do it, how perl5's tests are structured
>>to reduce interdependencies, use Test::More; when T
Andy Lester wrote in perl-qa :
> I can do this:
>
> use PHP::Session 0.10;
>
> to ensure a version number, but I can't do this:
>
> use_ok( 'PHP::Session', '0.10' );
The optional args to use_ok are for imports, not for version numbers.
[...]
> Before I go digging into a patch, is this
On 2002.01.14 22:27 Michael G Schwern wrote:
> B::Deparse has slowly gotten very good at figuring out BEGIN blocks
> from 'use' statements and putting them in the right places. Hard
> fought knowledge. Steal from it.
There are still problems with pragmas. (As I was working on B::Deparse
the las
On 2002.01.14 17:29 Michael G Schwern wrote:
> On Mon, Jan 14, 2002 at 11:13:27AM +0100, Rafael Garcia-Suarez wrote:
> > On 2002.01.13 22:25 Michael G Schwern wrote:
> > > Why would this:
> > >
> > > BEGIN {
> > > push @INC, 'foo&#x
On 2002.01.13 22:25 Michael G Schwern wrote:
> Why would this:
>
> BEGIN {
> push @INC, 'foo';
> }
>
> put 'foo' into @INC twice if it were compiled? The compiled program
> should not be storing the post-BEGIN value of @INC, it should store
> the original value at startup.
The
On 2002.01.05 23:45 Michael G Schwern wrote:
> Here's an interesting alternative. Do C just before
> running the tests, though that's pretty ugly.
Interesting idiom, but I don't see when this can be done.
> > But I rwally like the environment variable better, because with the
> > package variab
On 2001.10.20 17:16 Jarkko Hietaniemi wrote:
> On Sat, Oct 20, 2001 at 02:02:59AM -0400, Michael G Schwern wrote:
> > >
> > > I think installhtml teeters heavily on the brink of "Rewriting"
> > > instead of "Refactoring". It hasn't changed much since 1997.
> >
> > Refactoring is just rewriting
On 2001.09.19 17:37 Paul Marquess wrote:
> Nope, it does both. The test files that start with digits are intended to
> test the features of the warnings pragma itself along with it's interaction
> with $^W. All the other files test specific warnings.
>
> The tests for warnings::enabled and warnin
Michael G Schwern listed:
[...]
> warnings::register (almost no docs)
There are no tests for warnings.pm either.
Note that there are two distinct points here :
1. test the warnings issued by the perl interpreter; this is done by
lib/warnings.t, that calls the various files in t/lib/warnings/
18 matches
Mail list logo
