Blog

Latest Updates. News. Insights. Ideas.

May 2010 - Sahi Pro

Ruby Sahi with Cucumber

Posted by | BDD, Cucumber, Ruby, Sahi | 8 Comments

What is Cucumber?

Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.
– From http://cukes.info/

Follow the steps below to get started with Ruby Sahi and Cucumber.

  1. Install Java
  2. Install Ruby
  3. Install cucumber:
    gem install cucumber
  4. Install Sahi proxy: Download Sahi from sourceforge and unzip to some location. (say D:sahi)
  5. Start Sahi:

    cd D:sahiuserdatabin
    start_sahi.bat

  6. Install Sahi Ruby client:
    gem install sahi
  7. Create a file D:testlogin.feature, add the content below and save it.

    Feature: Login
    In order to access the system
    As a user
    I want to be able to login

    Scenario: Login with valid credentials
    Given I am not logged in
    When I try to login with "test" and "secret"
    Then I should be logged in

    Scenario: Login with invalid credentials
    Given I am not logged in
    When I try to login with "test" and "wrongpassword"
    Then I should not be logged in
    And I should be shown error message "Invalid username or password"

  8. Run this feature:

    cd D:test
    cucumber login.feature

    There will be a lot of messages with hints on implementing the right steps.

  9. Implement the steps:

    Create a file D:testlogin.rb, add the content below and save it


    require 'sahi'

    def init_browser()
    #Use the correct paths from your system
    userdata_dir = "D:/sahi/userdata"
    browser_path = "C:\Program Files\Mozilla Firefox\firefox.exe"
    browser_options = "-profile #{userdata_dir}/browser/ff/profiles/sahi0 -no-remote"
    return Sahi::Browser.new(browser_path, browser_options)
    end

    #open the browser at the start
    browser = init_browser()
    browser.open

    #close the browser on exit
    at_exit do
    browser.close
    end

    Given /^I am not logged in$/ do
    browser.navigate_to("/demo/training/index.htm")
    end

    When /^I try to login with "([^"]*)" and "([^"]*)"$/ do |username, password|
    browser.textbox("user").value = username
    browser.password("password").value = password
    browser.submit("Login").click
    end

    Then /^I should be logged in$/ do
    if !browser.button("Logout").exists?()
    raise "Not logged in"
    end
    end

    Then /^I should not be logged in$/ do
    if !browser.submit("Login").exists?()
    raise "Logged in"
    end
    end

    Then /^I should be shown error message "([^"]*)"$/ do |msg|
    value = browser.div("errorMessage").text()
    if value != msg
    raise "Incorrect message: #{value}"
    end
    end

  10. Run and watch the tests complete successfully

    cd D:test
    cucumber login.feature

  11. Done!

Sahi API _under added

Posted by | Uncategorized | One Comment

Continuing with our tradition of innovation for simplicity, Tyto adds another wonderful API to Sahi.

NOTE: _under will be available in Sahi’s next release

The problem:

Let us take the example of a dynamically generated grid. The example we use here is available at http://www.zkoss.org/zkdemo/userguide/#g7

We wish to assert the value of “Received” column for “Style Guide for ZK 3.5 released”. If we bring up the controller and CTRL-hover over that element, what we see is
_div(“2008/11/14 13:23:07”)
which is not useful as a finder.
Looking at the alternatives listed, we notice that none of them can really help.

To fix this, we shall try using _near.

1) We put

_div(0, _near(_div(“Style Guide for ZK 3.5 released”)))
into the Evaluate Expression box, and click Highlight. This highlights the “Style Guide” element itself.
2) We experiment with the index passed as the first parameter, and using Highlight, pinpoint on the correct accessor as
_div(4, _near(_div(“Style Guide for ZK 3.5 released”)))

But this will not make a good accessor.
Why?
Because, this uses an index which seems like it would change when another column is added before the Received column.

What we really want, is that element, which is UNDER _div(“Received”).

Introducing the _under API

_under(element):
_under is a POSITIONAL marker. What it means is that it checks for coordinate based alignment under a particular element within a specific threshold.
So, in our case, it will look for a div which is roughly positioned underneath _div(“Received”)

Here is the final accessor:

_div(0, _near(_div(“Style Guide for ZK 3.5 released”)), _under(_div(“Received”)))

Note how this accessor is independent of the order of the rows and the columns.

And then the testers lived happily ever after …

Notes:
This grid is not a simple table but actually composed of 2 tables, one for the header and one for the contents. So we could have approaced this problem using _cell(_table(2), “Style Guide for ZK 3.5 released”, 4), but again the 4 would trip us later if the order/number of columns changes.
_under(el) can be passed as a last parameter to any Sahi API.
NOTE: _under will be available in Sahi’s next release

Choosing the right web automation tool or web testing tool

Posted by | Uncategorized | No Comments

Web automation is a little trickier than most other automation because there are many combinations of browsers and operating systems and they are fast evolving too.

What do you look for before you choose a tool for web automation?

The answer may actually depend on what your organization specializes in. If you are a product company which ships applications meant only for Internet Explorer, you need not consider multi-browser support or Linux support. But if you develop outward facing web applications, you may need to test the application on multiple browsers.

Here are some factors you should consider before choosing a testing tool.

The tool:

  1. Should be techincally sound
    1. Should be able to identify elements/record on all browsers.
    2. Should handle complexities like HTTPS, Frames, IFrames, AJAX, dynamic ids.
    3. Should not need tinkering with source code of tool
    4. Should not require hard coded waits

  2. Should save time and effort for teams
    1. Ramp up time should be minimal. Users should get productive within an hour.
    2. Complexities like AJAX, dynamic ids, object identification etc. should be handled by the tool instead of passing it on to testers. *
    3. Should run reliably across browsers and operating systems to reduce re-runs and debugging effort.
    4. Should not be dependent on knowledge of various other tools/technologies.
    5. Should need minimal maintenance of scripts/code

  3. Should work with existing teams instead of requiring a drastic overhaul
    1. Should not require your teams to change from testers to developer testers, but let them easily pick up some scripting knowledge and get functional.
    2. Should not require expertise in various peripheral technologies like Java, Junit, TestNG, XPath, Firebug, Browser DOM etc. to just get started.

  4. Should require minimal stakeholders
    1. Should not need developer involvement for modification to application in the name of “testability”. Dynamic ids, elements without ids, etc. should be handled well by the tool. *

  5. Should be easy to scale testing teams
    1. Should be easy to hire and add more members to your testing team. This requires the tool to be simple to use.
    2. Should be able to move the teams across projects and products. This means that the tool needs to be sound enough to work with various technologies and frameworks.

  6. Should have authoritative support available
  7. Should be cost effective. The following need to be considered:
    1. Cost of acquiring the tool
    2. Cost of employing capable testers who can use the tool
    3. Cost of maintaining test infrastructure
    4. Cost of authoritative support

    Too often, especially with open source tools, the amount of money wasted in man hours due to limitations of the tool, incompatibility with existing expertise of team, lack of support etc. far outweighs the cost of acquiring alternative commercial tools. (Developers and testers with not much business experience invariably think that their time is not a cost to their company, and do not mind spending a week on an effort which should have lasted a day, thus wasting 25% of a month’s salary for a tool which may cost 10%)

* It is possible to just use the Sahi Controller and identify various elements reliably. Because tools like Selenium cannot record across frames, iframes, the tester is forced to learn to use Firebug to figure out what ID or XPath to use, add a line of selectFrame etc. These are very tool specific. While learning to use Firebug is an awesome skill to have, it should not be required at each step of the automation process. Adding conditional waits with knowledge of DOM is an unnecessary effort put on the tester, which can be handled by intelligent tools. Same goes for making developers add custom id generators for handling dynamic ids.

Use fully-loaded Sahi Pro FREE for a month. Download Now Request a Demo