ory . '/*' );
delete $final{$_} foreach @orig;
my @final = map { s{^$directory/}//; $_ } keys %final;
}
sub post_created : End(created) {
my( $block, $section, @v ) = @_;
my @final = _lsd( @_ );
eq_or_diff( [EMAIL PROTECTED], [EMAIL PROTECTED], test_name );
}
> On 2005-11-02, Luke Closs <[EMAIL PROTECTED]> wrote:
> >
> > Also, yesterday Test::WWW::Selenium was uploaded to CPAN, so Selenium
> > can now be driven by perl!
>
> Test::WWW::Selenium seems interesting, but I could use an example it
> would be useful to
thanks for the help! I think using the environment variable is a really
easy way to achieve my goal.
thanks again,
michael
Hi All,
I have been trying to find a way to combine the functionality of
Test::Harness with testing scripts that take a parameter.
Here is my situation: I am trying to test a database configuration for
one specific ID. This ID is essentially part of primary key for several
tables and we would like
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #30576]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30576 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the h
I'd say a lot of the trouble comes from the fact that you're using the
automated test framework for something that isn't an automated test.
You'll probably find that easiest thing to do is stick something like this
in your Makefile.PL
sub MY::postamble {
return << 'EOM';
bench: pure_all
> If they are to be documented anywhere it is in rt.cpan.org. The
Test::More
> documentation is not a bug tracking system.
> Sorry to be so troublesome about this, but as RFC 1925's Rule #1 states
> "It Has To Work".
But it doesn't work! The {} equals { key => []} bug even slightly harmless.
If
To:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC:
BCC:[EMAIL PROTECTED]
Subject:RE: puts(foot) on is_deeply() and overloading
> Jarkko, unless you get a fix from Fergal RSN, please reverse the
is_deeply()
> patch from Fergal in the core. I'll deal with the problem
Tony Bowden wrote:
> The author's intent is entirely irrelevant to whether or not something
> is a bug.
Wow. I had 2 possible responses in mind, this one was not on my radar at
all. That was top left corner in the last second of extra time but we
appear to be playing on 2 different pitches.
_enti
On Tue, Sep 09, 2003 at 08:50:06PM +0100, Fergal Daly wrote:
> It says it looks inside listrefs and hashrefs. That's all.
> Objects are not listrefs and hashrefs. They are sometimes made *from*
> such, but they are not such.
I think many people would disagree with you here but that's irrelevant
10 matches
Mail list logo
