Yes, I feel your pain on that one.
If you're only using Watir, such as I am currently, I found that it usually is
best to build your own [test] framework / API for your particular application.
It's actually sort of fun to build an API using Watir; there's nothing better
than three or four layers of abstraction to simplify things :)
The goal of your API should be to mimic business and user functions so that
you'll build the tools (methods) you need to create a comprehensive automated
test suite using Ruby/Watir. I would create a class that represents the object
your are testing, then build methods that control it. So for example, write
Watir methods for this classs that allow a user to login, process a claim, make
a payment, then logout. Once you have these simple functions in place, stick
your custom class as a [ require 'MyApp' ] inside of your test suite / case.
Now you can use these methods in your test cases.
<begin file>
require 'test/unit'
require 'IS' # <<< my custom class representing
class TC_LoginScreen < Test::Unit::TestCase
def setup()
$is = IS.new( "http://serverName/login.aspx"; )
end
def test_login_incorrect_password()
$is.login( "username", "badPassword" )
assert_equal( $is.get_errors(), "Invalid Password", "Password error should
have been displayed." )
end
def test_login_correct_password()
$is.login( "username, "goodPassword" )
assert_nil( $is.get_errors(), "No errors should have been thrown." )
end
You get the picture, also, it's usually best practice to limit your assertions
to one per test case.
More to come with questions,
Nathan Christie
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.openqa.org/thread.jspa?threadID=6344&messageID=17878#17878
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
