Why not just write this in Perl?

use strict;
use warnings;
use HTTP::WebTest;

my $webtest = HTTP::WebTest->new;

$webtest->run_tests([
    {
        test_name    => 'obtain google cheese',
        url          => 'http://www.google.com/webhp?complete=1&hl=en'
+,
        text_require => [ 'Cheese' ],
    },
    {
        test_name    => 'something that makes sense',
        url          => 'http://www.google.com',
        text_require => [ 'Google' ],
    },

]);
[download]

You want cheese? We can get you cheese. No Java needed.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

As written, WebDriver is not accessible outside of the TestSelenium class. Making it so is a Java problem, not Perl.

Different worlds . . . all that the Perl code can do is to invoke the Java routines as-presented.   It cannot dip into Java’s world and start manipulating its variables.   You will need first to address this purely on the Java side:   “can Java manipulate the browser-instance in this way?”   Only then can Perl, through Selenium, issue a request to the Java routine to do it.   (And, even then, only if the whole thing makes sense given the strictures of the stateless HTTP protocol, which is most unlikely.)

Have you ever used Inline::Java? Because it can do exactly what you assert it can’t. Namely create, access, extend Java as directly as one likes or has the stomach to map.

If you have no experience in a problem domain, offering advice is hurtful as often as it helpful.

As a matter of fact, yes.   But only briefly, because it was much more expedient to simply write the whole thing in the native language.   Here’s the relevant quote – and the problem – taken directly from the Perl web-page:

Then Perl asks the Java classes what public methods have been defined.   These classes and methods are available to the Perl program as if they had been written in Perl.

. . . but the phrase, “as if they had been written in Perl,” is somewhat misleading.   Perl has transparent access to Java’s foreign-function interfaces, but is no more privileged in that regard as would be any other client using a similar interface.

The two interpreter environments are running in tandem, using (in this case) Java’s public interfaces.   Those interfaces do not expose whatever is private, and they (of course, necessarily) do not have Perl-VM “doing” anything to, or directly with, the Java-VM’s environment, because languages never expose interfaces that would de-stabilize or compromise their own integrity, even in the name of testing.   As I read the OP, the latter is along those lines:   “you, Java, having created this var, let me, Perl, do with it.”   Your capacity to do this is, as I read it, too limited to support the requested scenario.

Java has testing frameworks comparable to, and in some ways superior to, those offered by Perl.   Therefore, if it were me, I would cleanly divide this testing scenario into three non-intersecting parts:   (1) a test of Perl by Perl; (2) a test of Java by Java; and (3) a test of the interface between them, specifically where those interfaces are meant to be “public interfaces offered by this Java app for the consumption by others.”

Although it may not seem so, and although I do not always explain myself too well, I don’t make comments here merely to see my handle showing up on a web page.   If I am mistaken, simply correct me.