Alien-Selenium
view release on metacpan or search on metacpan
MANIFEST.SKIP
META.yml
README.txt
selenium-core-0.8.3.zip
t/01_load.t
t/02_install.t
t/03_readystate.t
t/maintainer/dependencies.t
t/maintainer/kwalitee.t
t/maintainer/nobreakpoints.t
t/maintainer/nodebugwords.t
t/maintainer/pod-coverage.t
t/maintainer/pod-source.t
t/maintainer/pod.t
inc/My/Module/Build.pm view on Meta::CPAN
./Build test t/sometest.t lib/Foo/Bar.pm
For the developper's comfort, if only one test is specified in this
way, I<ACTION_test> assumes that I<verbose> mode is wanted (see
L<Module::Build/test>). This DWIM can be reversed on the command line:
./Build test verbose=0 t/sometest.t
In the case of running a single test, I<ACTION_test> also
automatically detects that we are running under Emacs' perldb mode and
runs the required test script under the Perl debugger. Running a
particular test under Emacs perldb is therefore as simple as typing:
M-x perldb <RET> /path/to/CPAN/module/Build test MyModule.pm
If a relative path is passed (as shown), it is interpreted relative to
the current directory set by Emacs (which, except under very bizarre
conditions, will be the directory of the file currently being
edited). The verbose switch above applies here by default,
conveniently causing the test script to run in verbose mode in the
debugger.
Like the original L<Module::Build/test>, C<./Build test> accepts
supplemental key=value command line switches, as exemplified above
with C<verbose>. Additional switches are provided by
I<My::Module::Build>:
=over
=item I<< use_blib=0 >>
Load modules from the B<source> directory (e.g. C<lib>) instead of the
build directories (e.g. C<blib/lib> and C<blib/arch>). I use this to
debug L<Inline::C> code in a tight tweak-run-tweak-run loop, a
situation in which the MD5-on-C-code feature of L<Inline> saves a lot
of rebuilds.
=item I<full_debugging=1>
Sets the FULL_DEBUGGING environment variable to 1 while running
C<./Build test>, in addition to any environment customization already
performed by L</customize_env>. Packages of mine that use L<Inline>
enable extra debugging when this environment variable is set.
=back
=head3 Dependent Option Graph
This feature wraps around L<Module::Build/prompt>,
L<Module::Build/get_options> and L<Module::Build/notes> to streamline
the programming of optional features into a ./Build.PL script. Here is
a short synopsis for this feature:
inc/My/Module/Build.pm view on Meta::CPAN
use File::Path qw(mkpath);
use File::Spec::Functions qw(catfile catdir splitpath splitdir);
use File::Basename qw(dirname);
use File::Spec::Unix ();
use File::Find;
=begin internals
=head2 Global variables
=head3 $running_under_emacs_debugger
Set by L</_massage_ARGV> if (you guessed it) we are currently running
under the Emacs debugger.
=cut
our $running_under_emacs_debugger;
=head2 Constants
=head3 is_win32
Your usual bugware-enabling OS checks.
=cut
use constant is_win32 => scalar($^O =~ /^(MS)?Win32$/);
inc/My/Module/Build.pm view on Meta::CPAN
=cut
sub ACTION_buildXS { }
=item I<ACTION_test>
Overloaded to add t/lib and t/inc to the test scripts' @INC (we
sometimes put helper test classes in there), and also to implement the
features described in L</Extended C<test> action>. See also
L</_massage_ARGV> for more bits of the Emacs debugger support code.
=cut
sub ACTION_test {
my $self = shift;
# Tweak @INC (done this way, works regardless of whether we'll be
# doing the harnessing ourselves or not)
local @INC = (@INC, catdir($self->base_dir, "t", "lib"),
catdir($self->base_dir, "t", "inc"));
# use_blib feature, part 1:
$self->depends_on("buildXS") if $self->use_blib;
my @files_to_test = map {
our $initial_cwd; # Set at BEGIN time, see L<_startperl>
File::Spec->rel2abs($_, $initial_cwd)
} (@{$self->{args}->{ARGV} || []});
if ($running_under_emacs_debugger && @files_to_test == 1) {
# We want to run this script under a slave_editor debugger, so
# as to implement the documented trick. The simplest way
# (although inelegant) is to bypass Module::Build and
# Test::Harness entirely, and run the child Perl
# ourselves. Most of the code below was therefore cobbled
# together from the real T::H version 2.40 and M::B 0.26
$self->depends_on('code'); # As in original ACTION_test
# Compute adequate @INC for sub-perl:
my @inc = do { my %inc_dupes; grep { !$inc_dupes{$_}++ } @INC };
if (is_win32) { s/[\\\/+]$// foreach @inc; }
inc/My/Module/Build.pm view on Meta::CPAN
sets FULL_DEBUGGING if so directed by the command line (see L</
ACTION_test>).
=cut
sub customize_env {
my ($self, %env) = @_;
delete $env{FULL_DEBUGGING};
$env{PERL_INLINE_BUILD_NOISY} = 1;
$env{FULL_DEBUGGING} = 1 if ($self->{args}->{full_debugging});
return %env;
}
=item I<process_pm_files>
Called internally in Build to convert lib/**.pm files into their
blib/**.pm counterpart; overloaded here to remove the test suite (see
L</Unit tests>) and standardize the copyright of the files authored by
me.
inc/My/Module/Build.pm view on Meta::CPAN
$opts{code}
KLUDGE_ME_UP
return $pack->SUPER::subclass(%opts);
}
=item I<_startperl>
Overloaded from parent to attempt a chdir() into the right place in
./Build during initialization. This is an essential enabler to the
Emacs debugger support (see L</ACTION_test>) because we simply cannot
tell where Emacs will be running us from.
=cut
sub _startperl {
my $self = shift;
my $basedir = $self->base_dir;
$basedir = Win32::GetShortPathName($basedir) if is_win32;
return $self->SUPER::_startperl(@_) . <<"MORE";
# Hack by My::Module::Build to give the Emacs debugger one
# more chance to work:
use Cwd;
BEGIN {
\$My::Module::Build::initial_cwd = \$My::Module::Build::initial_cwd =
Cwd::cwd;
chdir("$basedir") || 1;
}
MORE
}
inc/My/Module/Build.pm view on Meta::CPAN
=head2 Other Private Methods
=over
=item I<_massage_ARGV($ref_to_ARGV)>
Called as part of this module's startup code, in order to debogosify
the @ARGV array (to be passed as a reference) when we are invoked from
Emacs' M-x perldb. L</ACTION_test> will afterwards be able to take
advantage of the Emacs debugger we run under, by bogosifying the
command line back before invoking the script to test.
=cut
_massage_ARGV(\@ARGV);
sub _massage_ARGV {
my ($argvref) = @_;
my @argv = @$argvref;
return unless ($ENV{EMACS} && (grep {$_ eq "-emacs"} @argv));
$running_under_emacs_debugger = 1;
@argv = grep { $_ ne "-emacs" } @argv;
shift @argv if $argv[0] eq "-d"; # Was gratuitously added by former Emacsen
# XEmacs foolishly assumes that the second word in the perldb
# line is a filename and turns it into e.g. "/my/path/test":
(undef, undef, $argv[0]) = File::Spec->splitpath($argv[0]);
@$argvref = @argv;
}
inc/My/Tests/Below.pm view on Meta::CPAN
=item *
removing the My::Tests::Below altogether from the installed version
of a package is straightforward and does not alter line
numbering. (See L<My::Module::Build>)
=item *
no pre-processing step (e.g. C<inline2test>) and no temporary file
creation is required with My::Tests::Below. This goes a long ways
towards shortening the debugging cycle (no need to re-run "./Build
code" nor "make" each time)
=item *
L<Test::Inline> has a lot of dependencies, and using it would cause
the installation of small modules to become unduly burdensome.
=back
=cut "
inc/My/Tests/Below.pm view on Meta::CPAN
} else {
$self->{podsnippets}{$insnippet}->{text} .= $_ if (defined $insnippet);
};
next if (defined($packline) && $. <= $packline); # Be sure to
# catch the first marker *after* the require directive, and
# mind the self-test case too.
next SOURCELINE unless (m/^__(END|DATA)__\s+$/);
=item I<Line counting for the debugger>
You can step through the test using a GUI debugger (e.g. perldb in
Emacs) because the line numbers are appropriately translated.
=cut
$self->{testsuite}="#line ".($.+1)." \"$self->{packfilename}\"\n".
$self->{testsuite};
last SOURCELINE;
}
=item I<Tests always start in package main>
inc/My/Tests/Below.pm view on Meta::CPAN
($ragamount > $spaceamount));
}
s/^[ ]{$ragamount}//gm;
m/^(.*)$/s; return $1; # Untainted
}
=item I<pod_code_snippet($snippetname)>
Works like L</pod_data_snippet>, except that an adequate #line is
prepended for the benefit of the debugger. You can thus single-step
inside your POD documentation, yow! Using the above sample .pm file
(see L</pod_data_snippet>), you could do something like this in the
test trailer:
=for My::Tests::Below "POD testing example" begin
my $snippet = My::Tests::Below->pod_code_snippet("create-zoinx");
# Munging $snippet a bit before running it (e.g. with regexp
# replaces) is par for the course.
inc/Pod/Snippets.pm view on Meta::CPAN
piece of POD and execute it with L<perlfunc/eval>. This can readily
be done using your usual unit testing methodology, without too much
ajusting if any. This approach has some advantages over other
code-in-POD devices such as L<Pod::Tested> and L<Test::Inline>:
=over
=item *
There is no preprocessing step involved, hence no temp files and no
loss of hair in the debugger due to line renumbering.
=item *
Speaking of which, L</as_code> prepends an appropriate C<#line> if
possible, so you can single-step through your POD (yow!).
=back
The Pod-Snippets CPAN distribution consists of a single Perl file, and
has no dependencies besides what comes with a standard Perl 5.8.x. It
inc/Pod/Snippets.pm view on Meta::CPAN
return wantarray ? @retval : join("\n", @retval);
}
=head2 as_code ()
Returns the snippets formatted as code, that is, like L</as_data>,
except that each block is prepended with an appropriate C<#line>
statement that Perl can interpret to renumber lines. For instance,
these statements would cause Perl to Do The Right Thing if one
compiles the snippets as code with L<perlfunc/eval> and then runs it
under the Perl debugger.
=cut
sub as_code {
my ($self) = @_;
$self->_block_access_if_errors();
my @retval = $self->as_data;
foreach my $i (0..$#retval) {
my $file = $self->filename;
inc/Pod/Snippets.pm view on Meta::CPAN
if ((! defined $severity) || ($severity eq "ignore")) {
return;
} else {
$self->raise_pod_snippets_incident($severity, $message);
}
}
=head2 Fancy accessors
Yes, we want them even in a totally private class: they are so helpful
in making the code easier to understand, debug and refactor.
=head3 in_named_pod_snippet ($name, $boolean)
Tells the parser state machine that we are entering ($boolean true) or
leaving ($boolean false) a POD snippet named $name. This operation
can cause L</maybe_raise_pod_snippets_overlap> and/or
L</maybe_raise_pod_snippets_bad_pairing> to be invoked as a side effect.
=head3 in_named_pod_snippet ($name)
t/maintainer/nodebugwords.t view on Meta::CPAN
#!perl -w
use strict;
=head1 NAME
nodebugwords.t - Checks that there are no words such as DESIGNME, FIXME,
DOCUMENTME, XXX and so on left in the source code. Other markers
(such as UNIMPLEMENTED, OBSOLESCENT, OBSOLETE) are left alone.
=cut
use Test::More;
unless (eval <<"USE") {
use Test::NoBreakpoints qw(all_perl_files);
1;
USE
plan skip_all => "Test::NoBreakpoints required";
warn $@ if $ENV{DEBUG};
exit;
}
plan no_plan => 1;
foreach my $file (all_perl_files(qw(Build.PL Build lib t))) {
next if $file =~ m/nodebugwords\.t/; # Heh.
local *FILE;
open(FILE, $file) or die "Cannot open $file for reading: $!\n";
my ($badwords_count, $lineno);
while (<FILE>) {
$lineno++;
foreach my $badword (qw(DESIGNME FIXME DOCUMENTME XXX)) {
next unless m/\b$badword\b/;
diag "$badword found at $file line $lineno";
$badwords_count++;
}
}
ok(! $badwords_count, "no debug words found in $file");
}
( run in 1.527 second using v1.01-cache-2.11-cpan-49f99fa48dc )