Yitzchak Scott-Thoennes wrote:
I'd make that just:
sub main {
...the program using the functions below...
}
main() unless caller;
sub some_function { ... }
sub some_other_function { ... }
Nice trick. I just tested it.
[EMAIL PROTECTED] ~/test] cat foo.pl
#!/usr/bin/perl -w
use strict;
m
On Sun, Mar 06, 2005 at 10:32:26AM -0800, Michael G Schwern wrote:
> #!/usr/bin/perl -w
>
> use Getopt::Long;
>
> my %Opts;
> GetOptions(\%Opts, "test");
>
> sub main {
> return if $Opts{test};
>
> ...the program using the
On Sun, Mar 06, 2005 at 10:01:19PM +0100, C?dric Bouvier wrote:
> I have something almost working right now. I'd like to upload it to CPAN
> (after I have at least improved the documentation kindly written by
> Module::Starter, that is) but I'd like your enlightened opinion on what
> name it should
On Sun, Mar 06, 2005 at 09:54:44PM +0100, S?bastien Aperghis-Tramoni wrote:
> Instead of running the code on one server, where it's a problem, why
> not running on machines where all prereq modules are already installed,
> i.e. on machines where one *wants* to install the module ? Let's add an
>
I've been reading up on perl test tools all day, and I have a question
about Test::More.
Doesn't is_deeply do everything eq_array and eq_hash does and more? It
looks like is_deeply has the same exact interface and purpose, except
that it accepts both arrayrefs and hashrefs. So why would you n
Ive written some tests that verify writing to STDOUT, etc,
which were easy to do as `$X ... ` jobs.
but these dont get covered by default, so my coverage results are not
what they should be.
I tried to do the following, but it didnt work out.
my @args = ($^X,
(defined %Devel::Cover::)
Hello there.
I once had to organize the stress testing of a web based application.
The client wanted to know whether the server would handle a given number
of concurrent sessions and how long would the users have to wait in
front of their stalled browser if such a situation ever happened.
The app
Michael G Schwern wrote:
I think it would be a powerful addition to CPAN. If you go to the
distribution page for any module - say, for example, Class::DBI
(http://search.cpan.org/~tmtm/Class-DBI/)
Trouble right there. Now search.cpan.org has to run untrusted code so
a jail would have to be constr
Subject: Re: testing non-modules
From: Johan Vromans <[EMAIL PROTECTED]>
To: perl-qa@perl.org
}[Quoting Michael G Schwern, on March 6 2005, 10:32, in "Re: testing non-modu"]
}> Or if you want to be super portable you can do this:
}>
}> use Test::Output;
}> local @ARGV = qw(some args);
}
[Quoting Michael G Schwern, on March 6 2005, 10:32, in "Re: testing non-modu"]
> Or if you want to be super portable you can do this:
>
> use Test::Output;
> local @ARGV = qw(some args);
> stdout_is( sub { do "bin/myprogram" }, 'wibble' );
>
> Which has the nice side benefit of
Michael G Schwern wrote:
Now, nobody says this means your program has to be split up into a whole
bunch of files and become a full fledged module. You can write something
like this.
#!/usr/bin/perl -w
use Getopt::Long;
my %Opts;
GetOptions(\%Opts, "test");
s
On Sun, Mar 06, 2005 at 09:35:07AM -0800, Ofer Nave wrote:
> One issue I've always struggled with is how to properly test code that's
> not in the form of a module - in other words, scripts. I use the usual
> hacky, temporary methods to test my code as I write it or when I find a
> bug (pring s
> One issue I've always struggled with is how to properly test code that's
> not in the form of a module - in other words, scripts. I use the usual
Take a look at what I do with prove in Test::Harness. It's not very
in-depth but should give you a starting point.
--
Andy Lester => [EMAIL PRO
One issue I've always struggled with is how to properly test code that's
not in the form of a module - in other words, scripts. I use the usual
hacky, temporary methods to test my code as I write it or when I find a
bug (pring statements, commenting out things, etc), and occasionally the
perl
14 matches
Mail list logo
