Re: T::H 2.38
Andy Lester wrote in perl.qa :
>> prove begins with #!/usr/bin/perl and prove-switches.t
>> runs it with
>> my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/;
>> A $^X should be inserted here.
>> (in bleadperl, the shebang line of prove is fixed when installed.)
>
> What should be in prove's shebang?
The $Config{startperl} configure variable of the perl being installed.
Re: tesing exceptions of Error.pm
On Tue, Dec 02, 2003 at 10:05:46PM -0800, Michael G Schwern wrote:
> Why not?
>
> catch MyError with {
> like( $ex, qr/Bad thing/ );
> };
If there is no exception then then that test won't execute. It'd have to be
something like
try {
f();
fail("no exception");
}
catch MyError with {
like( $ex, qr/Bad thing/ );
};
but that runs the risk of forgetting the fail(),
F
thinking about Test::HTML::Form
Hello, Lately I've been using the excellent WWW::Mechanize module a good deal to test web applications. As I've done this, I've noticed a number of the same patterns coming up as I'm testing web-based forms. I'm wondering if there are any known modules out there for testing forms represented as HTML::Form objects, or interest in helping create such a module. Here are the test shortcuts I'm interested in so far: - found form named 'FOO' # Important to know you are testing the right form! - form contains exactly these fields - form contains at least these fields Additionally, I could see shortcuts for randomly or methodically selecting possible value combinations from selection lists, possibly with a focus on testing the edge cases, such as the first and last items in the group. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: tesing exceptions of Error.pm
On Wed, Dec 03, 2003 at 10:20:03AM +, Fergal Daly wrote:
> On Tue, Dec 02, 2003 at 10:05:46PM -0800, Michael G Schwern wrote:
> > Why not?
> >
> > catch MyError with {
> > like( $ex, qr/Bad thing/ );
> > };
>
> If there is no exception then then that test won't execute. It'd have to be
> something like
>
> try {
> f();
> fail("no exception");
> }
> catch MyError with {
> like( $ex, qr/Bad thing/ );
> };
>
> but that runs the risk of forgetting the fail(),
Ahh. Then I'd suggest something like this.
catch_like { f(); } 'MyError', qr/Bad thing/;
Where catch_like is something like:
my $TB = Test::Builder->new;
sub catch_like {
my($sub, $exception, $regex) = @_;
try {
$sub->();
};
$exception->catch(with { $TB->like( shift, $regex ) });
}
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
1. You are thin.
2. You look great.
3. You live in a castle with robot servants.
-- http://www.angryflower.com/anaddi.gif
RFC: CPAN QA Project
To further a discussion on [EMAIL PROTECTED] earlier today, There seems to be an increasing number of distributions suffering from atrophy. This can be caused from the authors losing interest, having insufficient time to maintain their work, and many other reasons. This situation oftentimes affects a significant number of important and widely-used distributions, preventing them from operating in a manner consistent with their intent. I suggested that it might be a sane idea to consider starting a project who's mission would be to take over the maintenance of distributions that, for lack of criteria with greater specificity: a) are popular, well-used distributions b) are no longer being actively maintained by their authors c) have unresolved rt tickets of a significant amount of time Preferrably, maintenance take-overs would occur with the blessing of said author. The scope of such maintenance take-overs would ideally be limited to fixing outstanding issues, ensuring nominal operation across platforms and perl versions, and addressing bugs reports made against the distribution via rt, etc. In the interest of staying focused, the CPAN QA Project would not be chartered to address new features, enhancements or wishlists. Chip mentioned that the Debian project has such a team, named the QA team. They have a concept of orphaned packages and inactive maintainers. Their QA team has a process[1] and critera for their team taking over the maintenace of qualifying packages[2]. There is a similar project, Phalanx[3], that address a correlative problem space, but has a different charter and set of goals. The CPAN QA project would not seek to duplicate the efforts of Phalanx, and would aim to be supplemental. Please note that I am not necessarily volunteering myself for this effort. I simply see a need for such a project and feel a discussion would be in the best interest. If someone feels particularly strong about initiating such a project, it would likely very much benefit the community. [1] http://debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa [2] http://qa.debian.org/orphaned.html [3] http://qa.perl.org/phalanx/ -- Adam J. Foxson
Re: thinking about Test::HTML::Form
* Mark Stosberg [2003/12/03 16:22]: > Lately I've been using the excellent WWW::Mechanize module a good deal > to test web applications. As I've done this, I've noticed a number of > the same patterns coming up as I'm testing web-based forms. > > I'm wondering if there are any known modules out there for testing > forms represented as HTML::Form objects, or interest in helping create > such a module. I had a hand in designing a web-based tester that used XPath expressions to determine if resulting HTML contained appropriate elements. This sounds like a technique that would be useful here, and anywhere else you needed to test HTML or XML content. You could do something like: my $html = get($uri); html_xpath($html, '//form[1]//[EMAIL PROTECTED] = "myButton"]/@value', 'Expected value'); Or something similar. html_xpath is a horrid name, but you get the idea. I don't have any code to contribute (the original was implemented by someone else, in Python), but the idea is mostly formed in my head. I'd be happy to contribute ideas and/or code to implement such a beast. (darren) -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization. pgp0.pgp Description: PGP signature
Re: RFC: CPAN QA Project
Hi!
On Wed, Dec 03, 2003 at 01:24:40PM -0500, Adam Foxson wrote:
> I suggested that it might be a sane idea to consider starting a project who's
> mission would be to take over the maintenance of distributions that, for lack
> of criteria with greater specificity:
>
> a) are popular, well-used distributions
> b) are no longer being actively maintained by their authors
> c) have unresolved rt tickets of a significant amount of time
a) and b) are hard to check, but c) would be an interesting metric for
CPANTS (release pending...).
You might be able to use low kwalitee ratings combined with an old release
date to locate even more unmaintained (or maybe just uninteresting)
distributions
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Test::Benchmark ??
putting a name to it is painting a bullseye on it ;-)
I recently wrote a test to do a benchmark / performance test,
and found it somewhat difficult to get the output out to screen,
the STDOUT, STDERR takeover done by Test::More was
catching, and counting it as errors. (i think, but its not pertinent)
I ended up doing this..
for $data ($AR, $HR, [EMAIL PROTECTED], $ezpr, $ddo) {
$rows = cmpthese(-3, {
'DD' => sub { Dumper ($data)},
'EzDD' => sub { $ezdd->($data)},
}, 'none');
# kinda hacked way of getting output..
for $r (@$rows) {
diag sprintf("%12s %12s %12s %12s", @$r);
}
}
IOW, since Benchmark::cmpthese() printing was blocked, I suppressed it,
then printed the rows myself with diag().
S
Is there a Test::* enhancement latent here ?
I could hack Benchmark to accept print-styles "#$foo",
where $foo is :
STYLE can be any of 'all', 'none', 'noc', 'nop'
or 'auto'. 'all' shows each of the 5 times
thus sneaking in a prefix that might allow it out of the Test::More
stdout/err box.
I dont know if this would work, but it sounds like a bad idea anyway-
it creates a dependency on a new Benchmark hack, which is in CORE,
and would then have to become dual-life.
Alternatively - Test::Benchmark could override the appropriate pieces
of Benchmark. This is only worthwhile if print "# foo" actually gets
thru the
test framework.
Finally, and perhaps most practically, diag_code (&;$) could run the
subroutine within a box that lets the prints thru. The biggest problem
is that
its probably hard to also catch errors/warnings etc that should be caught.
So what think yall ?
Re: T::H 2.38
my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/;
A $^X should be inserted here.
(in bleadperl, the shebang line of prove is fixed when installed.)
What should be in prove's shebang?
The $Config{startperl} configure variable of the perl being installed.
How can I get that in there? Or are you saying I should run it as
my @actual = qx/$Config{startperl} $prove -Ifirst /;
xoa
--
Andy Lester
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/ http://use.perl.org/~petdance/
