In my case, I started out with launching my server with plackup, but then I wanted a custom configuration and a fresh database, and I wanted to override how some functions return errors etc., and all of that becomes more cumbersome, together with the uncertainity whether I'm really connecting to the fresh instance and not a left-over instance from a previously interrupted test run.

But for a very simple start, this is an old version of the end-to-end test run setup I had:

package helper;
use strict;
use File::Path;
use File::Temp 'tempdir';
use WWW::Mechanize::Chrome;

sub spawn_app {
    my( $port ) = @_;
    
    my $h = helper::Child->new;
    $h->spawn_child( 'plackup', '-a', 'bin/app.pl', '-p', $port );
    $h
}

my @cleanup_directories;
END {
    File::Path::rmtree($_, 0) for @cleanup_directories;
}

sub spawn_chrome {
    my $tempdir = tempdir();
    push @cleanup_directories, $tempdir;
    my $mech = WWW::Mechanize::Chrome->new(
        launch_exe => '...',
        data_directory => $tempdir,
        @_
    );
}

package helper::Child;
use strict;

sub new {
    my( $class, %options ) = @_;
    bless \%options => $class;
}

sub DESTROY {
    kill 'KILL', $_[0]->{pid};
    wait;
}

sub spawn_child_win32 { my ( $self, @cmd ) = @_;
    system(1, @cmd)
}

sub spawn_child_posix { my ( $self, @cmd ) = @_;
    require POSIX;
    POSIX->import("setsid");

    # daemonize
    defined(my $pid = fork())   || die "can't fork: $!";
    if( $pid ) {    # non-zero now means I am the parent
        $self->log('debug', "Spawned child as $pid");
        return $pid;
    };
    #chdir("/")                  || die "can't chdir to /: $!";

    # We are the child, close about everything, then exec
    (setsid() != -1)            || die "Can't start a new session: $!"
+;
    open(STDERR, ">&STDOUT")    || die "can't dup stdout: $!";
    open(STDIN,  "< /dev/null") || die "can't read /dev/null: $!";
    open(STDOUT, "> /dev/null") || die "can't write to /dev/null: $!";
    exec @cmd;
}

sub spawn_child { my ( $self, @cmd ) = @_;
    my ($pid);
    if( $^O =~ /mswin/i ) {
        $pid = $self->spawn_child_win32(@cmd)
    } else {
        $pid = $self->spawn_child_posix(@cmd)
    };
    $self->{pid} = $pid;

    return $pid
}

1;
[download]

Used as:

use lib './t';
use helper;

my $port = 5099;
my $server = helper::spawn_app( $port );
my $mech = helper::spawn_chrome(
);

...
[download]

I did a little more research on Plack::Test. So it turns out you can use it to start up a server with $Plack::Test::Impl like so:

use lib 'lib';
BEGIN { $ENV{'DANCER_ENVIRONMENT'} = 'testing' }
use Log::Log4perl qw(:easy);
use VoteTracker;
use Test::More;
use Test::HTML::Content;
use Plack::Test;
use WWW::Mechanize::Chrome;

$Plack::Test::Impl = "Server";

Log::Log4perl->easy_init($ERROR);

my $app = VoteTracker->to_app;

my $test = Plack::Test->create($app);
my $port = $test->port;

my $mech = WWW::Mechanize::Chrome->new( headless => 1, report_js_error
+s => 1,   );
$mech->allow( javascript => 1 );
$mech->get("http://localhost:$port/path/to/page");

xpath_ok($mech->content, '//h1[text()="Hello"]', 'Has proper title');

done_testing;
[download]

So this is great. One thing I noticed, however, is that WWW::Mechanize::Chrome is really slow to load. If each test script fires up Chrome, it will take an exceedingly long time to run the tests. Is there a way I can share the Chrome instance across each test?

Update:I've never used it before but I'm thinking Test::Class might be what the doctor ordered to pull this off, right?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Yes, launching and tearing down WWW::Mechanize::Chrome is slow.

You could look at keeping a Chrome process around and (re)connect to it on every test run. This is basically possible through the (undocumented as I now see) tab parameter, which takes a regular expression or the word 'current'. Keeping a Chrome process around is mostly untested though, as I usually find it too cumbersome to deal with left-over state from previous test runs, like cookies or other data.