Watir Exception Handling?

[Daniella]

Hi guys,

I need to learn how to handle Watir exceptions, so i've been searching
and couldn't find a good tutorial about it (with specific examples for
Watir.) . Does anyone have worked with this before ??
Can anyone please give me some good resources or a brief
explanation?

Thanks

[Charley Baker]

Depends on what you mean. General exception handling is documented in the Pickaxe ruby book and a basic ruby question. If you have specific questions then ask them. The brief answer would be wrap your code in begin/rescue clauses if that's what you truly mean to do.

-Charley

[marekj]

This is a nice topic...
when you execute some watir code and something fatal happens Bret just decides to throw you a WatirException and if you don't 'catch' it .... ahem... rescue it as it is specified in Ruby (Ruby keeps track of excepiton in global var $!, let's call it DohBang) , then it lands by crashing your runtime script and all milk gets spilled and Doh!... no more fun. OR you can build yourself a 'rescue' landing platform, a specialized Ruby Hospital Helicopter Pad.

The simple way to look at this block design is this.

begin
rescue_____<----- landing here
ensure
end

so a quick example:

begin
 #do some code that will blow up.
rescue WatirException => ex
 #do somethign with the Exception object ex
 puts ex.backtrace #prints the exception stack
 puts ex.message #prints just the message like 'could not find window'
ensure
#this is a block where no matter what happens you want to execute it.
end

I really haven't found many good examples of working with begin/rescue (or throw/catch in java talk)
Currently in Watir there are 12 exceptions subclassing from WatirException.
see this: http://wtr.rubyforge.org/rdoc/classes/Watir/Exception.html
WatirException which is a subclass of RuntimeError and so on up to Exception class in Ruby.

Here is some info on Ruby Exception class.
http://www.noobkit.com/ruby-exception
fyi: backtrace is an array of strings. Each string tells you file name, line number and method if there was one. (well and the message that began it all)
and some info on 'raise' method
http://www.noobkit.com/ruby-kernel-raise

also look up this info from pickaxe.
http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_exceptions.html

So basically treat 'rescue' as a landing pad where all Exception objects land that were thrown by 'raise' method
you can have more than one 'landing', each one 'catching' different Exception quack or just rescue them all by not specifiying anything.
some fun code could be like this:

begin
 raise Watir::Exception::WatirException, "Here I was running. I have fallen and I can't get up. Rescue Me."
rescue WatirException => wex
 #right above we have built a landing pad for Exception that quacks like WatirException and we shoo-shoo  it to variable wex.

Now we can make wex quack by calling its methods

hope this makes sense...
marekj

www.testr.us | test objects modeling in ruby

[Daniella]

Hi Charley,

Sorry for not been specific but I'm starting with this of
posting... :P
I' ve read about begin/rescue clauses also raise and ensure, but I saw
different examples in which rescue is inside the begin block and
others that put it outside the block, the same for raise. And i wanted
to know which are the best practices to handle exceptions (Watir
esceptions).

I found a list of Watir exceptions in this page:
http://wtr.rubyforge.org/rdoc/classes/Watir/Exception.html
And i would like to know which are the most used...?

I'm starting to automate some test cases.. so I wrote a personal
library (very simple) that encapsulate most of watir events I used on
my test cases something like this:

def ClickButtonByName(sButtonName)
if ($ie.button(:name, sButtonName).exists?)
$ie.button(:name, sButtonName).click
$log.WritePassed("Click on: '#{sButtonName}' Button", "Done")
else
$log.WriteFailed("Click on: '#{sButtonName}' Button", "Failed,
Button not Found")
end
end

So at the same time the actions are logged in another file. Then I
call this methods from another ruby file in order to create the test
cases. Now my question is where i should put the begin/rescue clauses?
for example what if the button doesn't exist how can I handle this
exception with begin/rescue?

I'll be very thankful if you can clarify my doubts

Daniella

On Nov 8, 4:59 pm, "Charley Baker" <charley.ba...@gmail.com> wrote:
> Depends on what you mean. General exception handling is documented in the
> Pickaxe ruby book and a basic ruby question. If you have specific questions
> then ask them. The brief answer would be wrap your code in begin/rescue
> clauses if that's what you truly mean to do.
>
> -Charley
>

[Bret Pettichord]

marekj wrote:
> when you execute some watir code and something fatal happens Bret just
> decides to throw you a WatirException and if you don't 'catch' it ....
> ahem... rescue it as it is specified in Ruby (Ruby keeps track of
> excepiton in global var $!, let's call it DohBang) , then it lands by
> crashing your runtime script and all milk gets spilled and Doh!... no
> more fun. OR you can build yourself a 'rescue' landing platform, a
> specialized Ruby Hospital Helicopter Pad.

Or you can use a testing framework such as Test::Unit or Rspec which
automatically rescues and records exceptions.

WARNING. Once you start rescuing exceptions, you run the risk that your
tests will find problems that will not be reported. The only way to
mitigate this risk is to make sure that you have good unit tests for
your test harness (since that is what you are creating as soon as you
start rescuing exceptions). If you don't know how to unit test your
harness, you need to learn how to do that first before you start
rescuing exceptions.

Bret

--
Bret Pettichord
Lead Developer, Watir, http://wtr.rubyforge.org
Blog, http://www.io.com/~wazmo/blog

[marekj]

Thanks for the Warning Bret.

In my tests I don't 'rescue' any exceptions. TestUnit takes care of that. (and starting to do some 'spec' Behaviour/Example model)
However in my 'context setup' code I try to catch exceptions under specific circumstances to 'try again' the same test sometimes, or if I log in to web app and 'password expired' situation occurs I can catch the exception and handle the 'change password' scenario... - in this situation this is not my test yet, but I am tracking that setup as well.
thanks

marekj

www.testr.us | we swim in watir

[Charley Baker]

  Bret's warning about exception handling is exactly right. Our tests are not rescuing exceptions, we're using Test::Unit for the majority of our tests, RSpec in a few tests. Something like your example for instance could be written as:

assert($ie.button(:name, sButtonName).exists?)

using Test::Unit. The Test::Unit runner can then give you reports, either passing or failing and information that should help identify the error if any. This is much more simple and reliable than rolling our own framework to handle errors and reporting in our tests.

 That being said, I do have a lot of underlying framework code where we are dealing with exceptions and have unit tests (though we need more) for that layer of code.

 My general recommendation would be to understand and use the existing test frameworks first for your tests and reports - RSpec and Test::Unit (if I were to start out today I would use RSpec for my tests instead of Test::Unit).

 Then create your own supporting code for your test framework gradually as the need comes up. Unit tests for this layer are crucial and I'd highly recommend test driven or behavior driven development and only building what you need when you need it. A phrase that's probably been beaten to death which encapsulates this idea is building your framework out organically.

 HTH somewhat,

Charley

[marekj]

On Nov 9, 2007 12:24 PM, Charley Baker <charle...@gmail.com> wrote:

Then create your own supporting code for your test framework gradually as the need comes up. Unit tests for this layer are crucial and I'd highly recommend test driven or behavior driven development and only building what you need when you need it. A phrase that's probably been beaten to death which encapsulates this idea is building your framework out organically.

Charley

Thanks for reminding us this Charley... reminds me of Brian Marick's advice in his book "grow your scripts bit by bit, satisfying one real and immediate need after another, while still keeping the code clean"

the thing I try to ask myself every day is: Is this 'real and immediate need?' when I write test code.
marekj

www.testr.us | test design test code test refactor test

[Daniella]

marekj, Bret and Charly Thank you so much for your advices...you are
right if I use Test::Unit or Rspec I wont need to handle exceptions.
I'm strarting to aplying it from now :)

Daniella