Tellurium Tutorial Series: Javascript Events - the "respond" attribute
2 views
Skip to first unread message
John.Ji...@gmail.com
Nov 21, 2008, 2:10:18 PM11/21/08
to tellurium-users
Most web applications include Javascripts and thus, the web testing
framework must be able to handle the Javascript events.
Usually, JavaScript includes the following events:
------------------------------------------------------------------------------------------------
Event Handlers Applicable inside:
------------------------------------------------------------------------------------------------
onAbort <img> tags
onBlur window object, all form objects (ie: <input>), and
<frame>.
onClick Most visible elements such as <a>, <div>, <body>
etc.
onChange Use this to invoke JavaScript if the mouse goes
pass some link
onError Text fields, textareas, and select lists.
onFocus Most visible elements such as <a>, <div>, <body>
etc.
onLoad <body>, <img>, and <frame>
onMouseover Most visible elements such as <a>, <div>, <body>
etc.
onMouseout Most visible elements such as <a>, <div>, <body>
etc.
onReset <form> tag, triggered when the form is reset via
<input type="reset">.
onSelect Elements with textual content. Most commonly used
inside text fields and textareas.
onSubmit <form> tag, triggered when the form is submitted.
onUnload <body>
--------------------------------------------------------------------------------------------------
The web applications have already hooked in event handlers for
different java script events. What we really
care is to fire the appropriate events to trigger the event handlers.
Selenium has already provided methods to generate events such as
fireEvent(locator, "blur")
fireEvent(locator, "focus")
mouseOut(locator)
mouseOver(locator)
Tellurium was born with Javascript events in mind since it was
initially designed to test applications written using the DOJO
javascript framework. In the EventHandler class, you will see extra
events such as "blur", "focus", "mouseOut", and "mouseOver" are
automatically added to the appropriate actions. But there are overhead
for this since for each extra event, Tellurium has to call to Selenium
core to fire the event. Because of this, Tellurium provides you an
option to disable the extra events in the configuration file
TelluriumConfig.groovy,
//event handler
eventhandler{
//whether we should check if the UI element is presented
checkElement = true
//wether we add additional events like "mouse over"
extraEvent = true
}
If the extraEvent is false, no extra events will be fired. Without the
extra events, sometimes, you will see strange UI behavior during the
testing. For example, your cursor is not in the text box that you are
typing. But it is not an issue if that will not affect your test
results.
Sometimes, you have javascript on the web that you have to deal with,
for example, we have the following radio button,
<input type='radio' name='mas_address_key' value='5779'
onClick='SetAddress_5779()'>
Although we can define the radio button as follows,
RadioButton(uid: "billing", clocator: [name: 'mas_address_key', value:
'5779'])
but it will not be able to respond to the click event since the
Tellurium RadioButton only have the "check" and "uncheck" actions,
which is enough for the normal case. As a result, no "click" event/
action will be generated during the testing. How to address this
problem then?
The straightforward way might be to append the "click" action to the
"check" action in Tellurium core, but that will create extra overhead
for normal usages. The other way is to create a new UI object which
extends the RadioButton and has the extra "click" method, which
requires you to understand how to create new Tellurium UI objects. The
two ways are not so convenient for users. That is why the "respond"
attribute comes into play.
Because of the above reasons, we added the "respond" attribute to
Tellurium UI objects and the "respond" attribute could be used to
define whatever events you want the UI object to respond to.
Right now, we really only care about the "Blur", "Click", "Focus",
"MouseOver", "MouseOut" events. Be aware, if we have multiple events,
the order of events is important. Tellurium specifies the event order
as
MouseOver -> Focus -> (Actually Tellurium Action) -> MouseOut ->
Blur
The "Click" Event is different, Tellurium has the "click" method for
it. Tellurium will dynamically add the method "click" to the UI object
using Groovy metaprogramming if the user specifies that the UI object
should respond to the "Click" event.
Still take the above radio button as an example, the new Radio Button
can be defined as,
ui.Container(uid: "form", clocator: [whatever]){
RadioButton(uid: "billing", clocator: [name: 'mas_address_key',
value: '5779'], respond: ["click"])
}
That is to say, if you issue the following command
click "form.billing"
even the RadioButton does not have the click method defined by
default, it is still able to dynamically add the click method at
runtime and call it.
A more general example may look as follows,
InputBox(uid: "searchbox", clocator: [title: "Google Search"],
respond: ["click", "focus", "mouseOver", "mouseOut", "blur"])
Do not worry about the event order for the respond attribute,
Tellurium will automatically re-order the events and then process them
properly.
framework must be able to handle the Javascript events.
Usually, JavaScript includes the following events:
------------------------------------------------------------------------------------------------
Event Handlers Applicable inside:
------------------------------------------------------------------------------------------------
onAbort <img> tags
onBlur window object, all form objects (ie: <input>), and
<frame>.
onClick Most visible elements such as <a>, <div>, <body>
etc.
onChange Use this to invoke JavaScript if the mouse goes
pass some link
onError Text fields, textareas, and select lists.
onFocus Most visible elements such as <a>, <div>, <body>
etc.
onLoad <body>, <img>, and <frame>
onMouseover Most visible elements such as <a>, <div>, <body>
etc.
onMouseout Most visible elements such as <a>, <div>, <body>
etc.
onReset <form> tag, triggered when the form is reset via
<input type="reset">.
onSelect Elements with textual content. Most commonly used
inside text fields and textareas.
onSubmit <form> tag, triggered when the form is submitted.
onUnload <body>
--------------------------------------------------------------------------------------------------
The web applications have already hooked in event handlers for
different java script events. What we really
care is to fire the appropriate events to trigger the event handlers.
Selenium has already provided methods to generate events such as
fireEvent(locator, "blur")
fireEvent(locator, "focus")
mouseOut(locator)
mouseOver(locator)
Tellurium was born with Javascript events in mind since it was
initially designed to test applications written using the DOJO
javascript framework. In the EventHandler class, you will see extra
events such as "blur", "focus", "mouseOut", and "mouseOver" are
automatically added to the appropriate actions. But there are overhead
for this since for each extra event, Tellurium has to call to Selenium
core to fire the event. Because of this, Tellurium provides you an
option to disable the extra events in the configuration file
TelluriumConfig.groovy,
//event handler
eventhandler{
//whether we should check if the UI element is presented
checkElement = true
//wether we add additional events like "mouse over"
extraEvent = true
}
If the extraEvent is false, no extra events will be fired. Without the
extra events, sometimes, you will see strange UI behavior during the
testing. For example, your cursor is not in the text box that you are
typing. But it is not an issue if that will not affect your test
results.
Sometimes, you have javascript on the web that you have to deal with,
for example, we have the following radio button,
<input type='radio' name='mas_address_key' value='5779'
onClick='SetAddress_5779()'>
Although we can define the radio button as follows,
RadioButton(uid: "billing", clocator: [name: 'mas_address_key', value:
'5779'])
but it will not be able to respond to the click event since the
Tellurium RadioButton only have the "check" and "uncheck" actions,
which is enough for the normal case. As a result, no "click" event/
action will be generated during the testing. How to address this
problem then?
The straightforward way might be to append the "click" action to the
"check" action in Tellurium core, but that will create extra overhead
for normal usages. The other way is to create a new UI object which
extends the RadioButton and has the extra "click" method, which
requires you to understand how to create new Tellurium UI objects. The
two ways are not so convenient for users. That is why the "respond"
attribute comes into play.
Because of the above reasons, we added the "respond" attribute to
Tellurium UI objects and the "respond" attribute could be used to
define whatever events you want the UI object to respond to.
Right now, we really only care about the "Blur", "Click", "Focus",
"MouseOver", "MouseOut" events. Be aware, if we have multiple events,
the order of events is important. Tellurium specifies the event order
as
MouseOver -> Focus -> (Actually Tellurium Action) -> MouseOut ->
Blur
The "Click" Event is different, Tellurium has the "click" method for
it. Tellurium will dynamically add the method "click" to the UI object
using Groovy metaprogramming if the user specifies that the UI object
should respond to the "Click" event.
Still take the above radio button as an example, the new Radio Button
can be defined as,
ui.Container(uid: "form", clocator: [whatever]){
RadioButton(uid: "billing", clocator: [name: 'mas_address_key',
value: '5779'], respond: ["click"])
}
That is to say, if you issue the following command
click "form.billing"
even the RadioButton does not have the click method defined by
default, it is still able to dynamically add the click method at
runtime and call it.
A more general example may look as follows,
InputBox(uid: "searchbox", clocator: [title: "Google Search"],
respond: ["click", "focus", "mouseOver", "mouseOut", "blur"])
Do not worry about the event order for the respond attribute,
Tellurium will automatically re-order the events and then process them
properly.
Reply all
Reply to author
Forward
0 new messages