- Better diagnostics (not just OK / NOT OK, but also for example WHY)
- Capability to skip tests given a range of criteria
- Capability to test futures features (using TODO)
- Compare complicated data structures
- Navigate the login page
- Make sure we are in the correct starting point
- Enter our login credentials
- Login to the site
- Verify our landing page after the login operation.
1: $driver->get($page); 2: my $loc1 = $driver->get_current_url(); 3: is ( $loc1, LOGINHOME, 'Verify landing page' ); # THIS IS TEST 1 4: login_as( $user_id, $password ); 5: my $loc2 = $driver->get_current_url(); 6: is ( $loc2, APPHOME, 'Verify landing page after login' ); # THIS IS TEST 2
In line 1 we navigate to our starting page (the login page) using Selenium's
getmethod. In line 2 we declare a variable that will hold the URL we just navigated to and that will be returned by Selenium's
get_current_urlmethod. Then, in line 3, we utilize Test::More's
is()is function to assert that the page we landed on, '$loc1', is in fact the expected one 'LOGINHOME'. Line 4 executes a page object who's sole purpose is to login to the web application under test. After the login operation we once again get the url of the page we landed on, '$loc2', and compare that to the page we expect to be after the login which is 'APPHOME'.
NOTE: I used the term Selenium above for readability to refer to Selenium::Remote::Driver - the Perl binding to WebDriver.
Below is the output that would be sent to the harness in a PASS case:
ok 1 - Verify landing page ok 2 - Verify landing page after login
And the output for a FAIL case:
not ok 1 - Verify landing page not ok 2 - Verify landing page after login
Whenever a test fails, one of the features of Test::More is that it gives you meaningful information (the whys) you can use when evaluating test failures. For example, in the above failure the following would be sent to the error output file:
# Failed test 'Verify landing page' # at C:\Users\Freddy Vega\SsApp\create_decision_tree.pl line 107. # got: 'http://myapp.com/myloginpage' # expected: 'http://myapp.com/Account/Login' # Failed test 'Verify landing page after login' # at C:\Users\Freddy Vega\SsApp\create_decision_tree.pl line 113. # got: 'http://myapp.com/Apphome' # expected: 'http://myapp.com/Home' # Looks like you failed 2 tests of 2.
As you can probably see by now, testing with Perl means not to re-invent the wheel every time a testing problem arises. In our solution we were able to use Selenium::Remote::Driver to drive our application under test (a web app). We used Test::More to make our assertions while we are testing and TAP::Harness to tie it all together and produce results that can later be mined, interpreted and presented to different audience types (management, users, developers, etc).
In the next post in this series I tell you about test harnesses and how you can combine these with other tools to help you design a robust automation framework.