Skip to Content
Last modified by Ray Kiddy on 2009/09/03 12:13
From version 10.1
edited by Kieran Kelleher
on 2007/11/10 13:58
Change comment: There is no comment for this version
To version 15.1
edited by Ray Kiddy
on 2009/09/03 12:13
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.kieran
1 +XWiki.kiddyr
Content
... ... @@ -10,6 +10,25 @@
10 10  
11 11  === General Approach to Developing a Test ===
12 12  
13 +Using the Selenium IDE, you can record a test to get a feel for the syntax of Selenium commands, or to quickly see the syntax for a specific type of user interface interaction, however, recorded tests are generally very fragile and will fall apart on dynamic pages where the layout and content are not static.
14 + So before we discuss building robust tests, let's first itemize our objectives or criteria under which our tests should operate robustly:
15 +
16 +* Localization - if user interface text in submit buttons, links, etc. can change depending on the selected language, then we don't want to depend on those for identifying ui elements in our Selenium tests
17 +* Data entry - rather than tediously program data entry for new enterprise objects, it is worth considering adding a [[doc:WONDER.Auto Development Defaults]] feature that can be enabled in Properties. Such a feature would assign default values (random, fixed, serial or otherwise) to attributes in EOEnterpriseObject's awakeFromInsertion method. This is a much more powerful way to generate input values serverside in java that in Selenium. Consequently, your Selenium tests will become much shorter and simpler, resulting in them consisting mostly of user click interactions.
18 +
19 +== Developing a Test ==
20 +
21 +* First fire up your WebObjects application and open the Selenium IDE
22 +* In the Selenium IDE, insert commands for each user action.
23 +* The most common commands you will use are clickAndWait, addSelection, open.
24 +* Specifying targets can be really easy as long as you are willing to sprinkle passive test identifiers into your WOComponents.
25 +** The easiest approach is to assign css classes to the elements you want to click on and then use that to identify the HTML element that is being clicked. So while your WO app is running, you can add css identifiers to the static or dynamic elements in your WOComponent, then save and refresh the page. Using FireBug's Inspect feature will allow you to easily verify the presence of your locator identifier.
26 +** Other approaches:
27 +*** Assign ids to html elements if you are sure the element will only ever appear once on the page. With the css class identifiers, Selenium will act on the first one it locates in the page.
28 +*** Wrap an element in a span tag and assign a css class or id to the span tag. Then you can make a Selenium locator expression that can click on some element type inside the span container.
29 +
30 +Probably the best way to understand Selenium command, target, value combinations is by looking at the [[doc:Selenium Command Examples]].
31 +
13 13  === Using ERSelenium's meta tag features for advanced test development ===
14 14  
15 15  == Using @include meta tag ==
... ... @@ -23,3 +23,11 @@
23 23  The @repeat tag denotes the beginning of the portion to be repeated and the @done denotes the end of the portion to be repeated. These (can/cannot?) be nested?
24 24  
25 25  The first pass thru the repeated segment, the actual values in the test are used and on consecutive repetitions the items from the @values list are substituted into the value part (the 3rd column) of the step immediately following the @values declaration
45 +
46 +See also: [[doc:Selenium]]
47 +
48 +{{panel title="WIKITODO"}}
49 +~* Flesh this out more with screenshots and examples for meta tags usage
50 +{{/panel}}
51 +
52 +\\