GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  SELENIUM::REMOTE::MOCK::REMOTECONNECTION (3)

.ds Aq ’

NAME

Selenium::Remote::Mock::RemoteConnection - utility class to mock the responses from Selenium server

CONTENTS

VERSION

version 0.23

SYNOPSIS

    Record interactions



    #!perl
    use strict;
    use warnings;
    use Selenium::Remote::Driver;
    use Selenium::Remote::Mock::RemoteConnection;

    # create a new Mock object to record the interactions with Selenium
    # Server
    my $mock_connection = Selenium::Remote::Mock::RemoteConnection->new( record => 1 );

    # the Mock object is passed to the driver in place of what would be
    # a regular Selenium::Remote::RemoteConnection object
    my $driver = Selenium::Remote::Driver->new( remote_conn => $mock_connection );

    # always store the session id, as it will become undef once
    # $driver->quit is called
    my $session_id = $driver->session_id;

    # do all the selenium things and quit
    $driver->get(http://www.google.com);
    $driver->get(http://www.wikipedia.com);
    $driver->quit;

    # dump the session to a file
    $mock_connection->dump_session_store( my_record.json );



This code, above doing some basic Selenium interactions, will end up generating a JSON file containing all the requests and their responses for your Selenium session. The JSON file looks like this :



    {
        "HTTP_REQUEST URL {request_parameters}":[ARRAY_OF_RESPONSES]
        ...
    }



The reason why we store array of responses is that the exact same request can be made more than once during a session, so we have to store every response to the same requests.

    Replay interactions



    #!perl
    use strict;
    use warnings;
    use Test::More;
    use Test::Selenium::Remote::Driver;
    use Selenium::Remote::Mock::RemoteConnection;
    my $mock_connection_2 =
      Selenium::Remote::Mock::RemoteConnection->new( replay => 1,
        replay_file => my_record.json );
    # javascript + version parameters added or else it will not work
    my $driver =
      Test::Selenium::Remote::Driver->new( remote_conn => $mock_connection_2, javascript => 1, version =>  );
    $driver->get_ok(http://www.google.com);
    $driver->get_ok(http://www.wikipedia.com);
    $driver->quit;
    done_testing;



Using the file generated with the recording snippet from the section before, we are able to mock the responses.

Note that there is one small limitation (that I hope to remove in future versions), is that a record generated with Selenium::Remote::Driver is not directly useable with Test::Selenium::Remote::Driver. This is mainly because the way the two instances are created are a bit different, which leads to different requests made, for creating a session for instance. For now, what works for sure is recording and replaying from the same class.

    Mock responses



    #!perl
    use Test::More;
    use Test::Selenium::Remote::Driver;
    use Selenium::Remote::WebElement;
    use Selenium::Remote::Mock::Commands;
    use Selenium::Remote::Mock::RemoteConnection;

    my $spec = {
        findElement => sub {
            my (undef,$searched_item) = @_;
            return { status => OK, return => { ELEMENT => 123456 } }
              if ( $searched_item->{value} eq q );
            return { status => NOK, return => 0, error => element not found };
        },
        getPageSource => sub { return this output matches regex},
    };
    my $mock_commands = Selenium::Remote::Mock::Commands->new;

    my $successful_driver =
      Test::Selenium::Remote::Driver->new(
        remote_conn => Selenium::Remote::Mock::RemoteConnection->new( spec => $spec, mock_cmds => $mock_commands ),
        commands => $mock_commands,
    );
    $successful_driver->find_element_ok(q,find_element_ok works);
    dies_ok { $successful_driver->find_element_ok(notq) } find_element_ok dies if element not found;
    $successful_driver->find_no_element_ok(notq,find_no_element_ok works);
    $successful_driver->content_like( qr/matches/, content_like works);
    $successful_driver->content_unlike( qr/nomatch/, content_unlike works);

    done_testing();



Mocking responses by hand requires a more advanced knowledge of the underlying implementation of Selenium::Remote::Driver. What we mock here is the processed response that will be returned by Selenium::Remote::RemoteConnection to ’_execute_command’ call. To accomplish this we need :
o a spec: a HASHREF which keys are the name of the methods we want to mock. Note that those keys should also be valid keys from the _cmds attribute in Selenium::Remote::Command. The value of each key is a sub which will be given two parameters:
o $url_params : the values that should have been replaced in the URL For instance, on the example above, it would have been:
{ session_id => ’some_session_id’}
o $params : the original parameters of the request. On the example above it would have been:
{ value => ’q’, using => ’xpath’}

The sub used as a value in the spec is not expected to return anything, so you have to craft very carefully what you return so that it will produce the expected result.

o a mock_cmd: a Selenium::Remote::Mock::Commands object. This is used mainly to hijack the normal commands so that placeholders do not get replaced in the URLs.

DESCRIPTION

Selenium::Remote::Mock::RemoteConnection is a class to act as a short-circuit or a pass through to the connection to a Selenium Server. Using this class in place of Selenium::Remote::RemoteConnection allows to:
o record interactions with the Selenium Server into a JSON file
o replay recorded interactions from a JSON file to mock answers from the Selenium Server
o mock responses to specific functions

BUGS

This code is really early alpha, so its API might change. Use with caution !

SEE ALSO

Please see those modules/websites for more information related to this module.
o Selenium::Remote::Driver

BUGS

Please report any bugs or feature requests on the bugtracker website https://github.com/gempesaw/Selenium-Remote-Driver/issues

When submitting a bug or request, please include a test-file or a patch to an existing test-file that illustrates the bug or desired feature.

AUTHORS

o Aditya Ivaturi <ivaturi@gmail.com>
o Daniel Gempesaw <gempesaw@gmail.com>
o Luke Closs <cpan@5thplane.com>
o Mark Stosberg <mark@stosberg.com>

COPYRIGHT AND LICENSE

Copyright (c) 2010-2011 Aditya Ivaturi, Gordon Child

Copyright (c) 2014 Daniel Gempesaw

Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 SELENIUM::REMOTE::MOCK::REMOTECONNECTION (3) 2015-01-25

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.