|
UserGuide070TelluriumSubprojects
Tellurium User Guide: Tellurium Subprojects
(A PDF version of the user guide is available here) Tellurium SubprojectsTellurium began as a small core project and quickly generated multiple sub-projects including: JUnit and TestNG, Maven Archetypes, TrUMP, Widget extensions, Core, and Engine projects as shown in the following diagram in Figure 3-1: Figure 3-1 Tellurium Subprojects
Tellurium Reference ProjectsTellurium has created reference projects to demonstrate how to use Tellurium for a user’s testing project. In the reference projects, Tellurium project web site is used as an example of illustrating how to write real-world Tellurium tests. The reference projects only use tellurium jar files and there are two sub-projects at the time of this document:
Basically, the two sub-projects are the same and the only difference is that tellurium-junit-java uses JUnit 4 and tellurium-testng-java uses TestNG. Hence, the only focus is on the tellurium-junit-java project. The tellurium-junit-java project illustrates the following usages of Tellurium:
Tellurium Maven ArchetypesTellurium provides two maven archetypes. For example: tellurium-junit-archetype for Tellurium JUnit test projects and tellurium-testing-archetype for Tellurium TestNG test projects. Run the following Maven command to create a new JUnit test project: mvn archetype:create -DgroupId=your_group_id -DartifactId=your_artifact_id \
-DarchetypeArtifactId=tellurium-junit-archetype \
-DarchetypeGroupId=tellurium -DarchetypeVersion=0.6.0Without adding the Tellurium Maven repository, specify it in the command line as: mvn archetype:create -DgroupId=your_group_id -DartifactId=your_artifact_id \
-DarchetypeArtifactId=tellurium-junit-archetype \
-DarchetypeGroupId=tellurium -DarchetypeVersion=0.6.0 \
-DarchetypeRepository=http://maven.kungfuters.org/content/repositories/releasesFor a TestNG archetype project, use a different archetype: mvn archetype:create -DgroupId=your_group_id -DartifactId=your_artifact_id \
-DarchetypeArtifactId=tellurium-testng-archetype \
-DarchetypeGroupId=tellurium -DarchetypeVersion=0.6.0 \
-DarchetypeRepository=http://maven.kungfuters.org/content/repositories/releasesTellurium UI Module Plugin (TrUMP)Go to the Tellurium project download page and download the TrUMP xpi file or download the Firefox 3 version directly from the Firefox Addons site at: https://addons.mozilla.org/en-US/firefox/addon/11035 The Tellurium UI Module Plugin (TrUMP) automatically generates UI modules for users. An example of the TrUMP IDE is shown in Figure 3-2: Figure 3-2 TrUMP IDE
The workflow of TrUMP is shown in Figure 3-3: Figure 3-3 TrUMP Workflow
TrUMP Workflow Procedure
Figure 3-4 Tellurium Download Page
The blue color indicates selected element. Click the selected element again to de-select it. Then, click on the "Generate" button to create the Tellurium UI Module. The user is automatically directed to the "Source" window. See Figure 3-5. Figure 3-5 Tellurium Download Page Source Window
Click the "Customize" button to change the UI module such as UIDs, group locating option, and attributes selected for the UI module. See Figure 3-6 Figure 3-6 Tellurium Download Page Changed UI Module
One red "X" mark is displayed, indicating the UI element's XPath is not unique. Select group, or add more attributes to the UI element. The user sees the new customized UI as shown in Figure 3-7: Figure 3-7 Tellurium Download Page Customized UI
Note: The red "X" mark is removed because Tellurium turned on the group locating and the element's xpath is now unique. In the meantime, the UI module in the source tab is automated and updated once the "Save" button is clicked. The "Show" button shows the actual Web element on the web for which the UI element is represented. See Figure 3-8. Figure 3-8 Tellurium Download Page Web Element
At this point, export the UI module to a groovy file. Be aware that if any error is seen complaining about the directory, first check the "export directory" in Options > Settings and set it to "C:\" or other windows directory for the Windows system before you export the file. For Linux, the user may find there is no "OK" button on the option tab, which is caused by the configure "browser.preferences.instantApply" is set to true by default. Point the firefox to "about:config" and change the option to false. Once this is completed, the user sees the "OK" button. See Figure 3-9. Figure 3-9 Tellurium Download Page UI Module in Groovy File
Open the groovy file to view the following: package tellurium.ui
import org.tellurium.dsl.DslContext
/**
* This UI module file is automatically generated by TrUMP 0.1.0.
*
*/
class NewUiModule extends DslContext{
public void defineUi() {
ui.Container(uid: "Tellurium", clocator: [tag: "body", class: "t2"]){
Form(uid: "Form", clocator: [tag: "form", method: "get", action: "list"],
group: "true")
{
Selector(uid: "DownloadType", clocator: [tag: "select", name: "can", id: "can"])
InputBox(uid: "SearchBox", clocator: [tag: "input", type: "text", name: "q",
id: "q"])
SubmitButton(uid: "Search", clocator: [tag: "input", type: "submit",
value: "Search"])
}
Container(uid: "Title", clocator: [tag: "table", id: "mt"]){
UrlLink(uid: "Issues", clocator: [tag: "a", text: "Issues"], respond: ["click"])
UrlLink(uid: "Wiki", clocator: [tag: "a", text: "Wiki"], respond: ["click"])
UrlLink(uid: "Downloads", clocator: [tag: "a", text: "Downloads"],
respond: ["click"])
}
}
}
//Add your methods here
}Tellurium Widget ExtensionsThe Tellurium Widget Extensions are a way of re-using UI components when testing. Tellurium provides the capability to composite UI objects into a widget object and then use that widget directly as if using a Tellurium UI object. The advantage is that a user does not need to deal with the UI at the link or button level for the widget, just work on the high level methods. Another advantage is that this widget is reusable. Usually, Java script frameworks provide a number of widgets. For example. the Dojo framework: Tellurium uses the widget DatePicker to prototype the Tellurium widget. For widgets, it is important to include name space to avoid name collision among different widget modules. For example, what is Dojo and ExtJs? Both have the widget Date Picker. After adding the name space, the widget is named as "DOJO_DatePicker". The DataPicker widget is defined as a normal Tellurium UI module: class DatePicker extends DojoWidget{
public void defineWidget() {
ui.Container(uid: "DatePicker", locator: "/div[@class='datePickerContainer'
and child::table[@class='calendarContainer']]"){
Container(uid: "Title", locator: "/table[@class='calendarContainer']/thead
/tr/td[@class='monthWrapper']/table[@class='monthContainer']/tbody
/tr/td[@class='monthLabelContainer']"){
Icon(uid: "increaseWeek", locator:
"/span[@dojoattachpoint='increaseWeekNode']")
Icon(uid: "increaseMonth", locator:
"/span[@dojoattachpoint='increaseMonthNode']")
Icon(uid: "decreaseWeek", locator:
"/span[@dojoattachpoint='decreaseWeekNode']")
Icon(uid: "decreaseMonth", locator:
"/span[@dojoattachpoint='decreaseMonthNode']")
TextBox(uid: "monthLabel", locator:
"/span[@dojoattachpoint='monthLabelNode']")
}
StandardTable(uid: "calendar", locator: "/table[@class='calendarContainer']
/tbody/tr/td/table[@class='calendarBodyContainer']"){
TextBox(uid: "header: all", locator: "")
ClickableUi(uid: "all", locator: "")
}
Container(uid: "year", locator: "/table[@class='calendarContainer']/tfoot
/tr/td/table[@class='yearContainer']/tbody/tr/td/h3[@class='yearLabel']"){
Span(uid: "prevYear", locator: "/span[@class='previousYear' and
@dojoattachpoint='previousYearLabelNode']")
TextBox(uid: "currentYear", locator: "/span[@class='selectedYear' and
@dojoattachpoint='currentYearLabelNode']")
Span(uid: "nextYear", locator: "/span[@class='nextYear' and
@dojoattachpoint='nextYearLabelNode']")
}
}
}
}Here the XPath is used directly for demonstration purposes only. Usually the composite locator is used instead. Also, Tellurium defines the following widget methods: public String getCurrentYear(){
return getText("DatePicker.year.currentYear")
}
public void selectPrevYear(){
click "DatePicker.year.prevYear"
}The widget is treated as a Tellurium UI object and the builder is the same as regular Tellurium objects: class DatePickerBuilder extends UiObjectBuilder{
public build(Map map, Closure c) {
//add default parameters so that the builder can use them if not specified
def df = [:]
DatePicker datepicker = this.internBuild(new DatePicker(), map, df)
datepicker.defineWidget()
return datepicker
}
}Now, the user hooks the widget into the Tellurium Core. Each widget module is compiled as a separate jar file and Tellurium defines a bootstrap class to register all the widgets inside the module. By default, the full class name of the bootstrap class is org.tellurium.widget.XXXX.Init, where the class Init implements the WidgetBootstrap interface to register widgets and XXXX stands for the widget module name. It is DOJO in this case. class Init implements WidgetBootstrap{
public void loadWidget(UiObjectBuilderRegistry uiObjectBuilderRegistry) {
if(uiObjectBuilderRegistry != null){
uiObjectBuilderRegistry.registerBuilder(getFullName("DatePicker"),
new DatePickerBuilder())
}
}
}Then in the tellurium configuration file TelluriumConfig.groovy, include the module name there: widget{
module{
//define your widget modules here, for example Dojo or ExtJs
included="dojo"
}
}If the user’s own package name is used for the bootstrap class, for example, com.mycompay.widget.Boot, then specify the full name here. widget{
module{
//define your widget modules here, for example Dojo or ExtJs
included="com.mycompay.widget.Boot"
}
}Note: Load multiple widget modules into the Tellurium Core framework by definition. included="dojo, com.mycompay.widget.Boot" To use the widget, treat a widget as a regular Tellurium UI object. For example: class DatePickerDemo extends DslContext{
public void defineUi() {
ui.Form(uid: "dropdown", clocator: [:], group: "true"){
TextBox(uid: "label", clocator: [tag: "h4", text: "Dropdown:"])
InputBox(uid: "input", clocator: [dojoattachpoint: "valueInputNode"])
Image(uid: "selectDate", clocator: [title: "select a date",
dojoattachpoint: "containerDropdownNode", alt: "date"])
DOJO_DatePicker(uid: "datePicker", clocator: [tag: "div",
dojoattachpoint: "subWidgetContainerNode"])
}
}
}Then on the module file DatePickerDemo, call the widget methods instead of dealing with low level links, buttons, etc. To make the testing more expressive, Tellurium provides an onWidget method: onWidget(String uid, String method, Object[] args) In that way, call the widget methods as follows: onWidget "dropdown.datePicker", selectPrevYear Tellurium CoreThe Tellurium Core does Object to Locator Mapping (OLM) automatically at runtime so that UI objects are simply defined by their attributes. For example, Composite Locators denoted by the "clocator". Furthermore, Tellurium Core uses the Group Locating Concept (GLC) to exploit information inside a collection of UI components to help find their locators. The Tellurium Core defines a new Domain Specific Language (DSL) for web testing. One very powerful feature of Tellurium Core is that a user can use UI templates& to represent many identical UI elements or dynamic sizes of different UI elements at runtime. This is extremely useful to test a dynamic web such as a data grid. One typical data grid example is as follows: ui.Table(uid: "table", clocator: [:]){
InputBox(uid: "row: 1, column: 1", clocator: [:])
Selector(uid: "row: *, column: 2", clocator: [:])
UrlLink(uid: "row: 3, column: *", clocator: [:])
TextBox(uid: "all", clocator: [:])
} Data Driven Testing is another important feature of Tellurium Core where a user can define data format in an expressive way. In the data file, a user specifies which test to run, the input parameters, and expected results. Tellurium automatically binds the input data to variables defined in the test script and runs the tests specified in the input file. The test results are recorded by a test listener and the output is in different formats. For example, an XML file. The Tellurium Core is written in Groovy and Java. The test cases can be written in Java, Groovy, or pure DSL. A user does not need to know Groovy before using it because the UI module definition and actions on UIs are written in DSLs and the rest may be written in Java syntax. Tellurium EngineUp to Tellurium 0.6.0, Tellurium still leveraged Selenium core as the test driving engine. Selenium has a rich set of APIs to act on individual UI elements, and Tellurium can use them directly. Tellurium embedded its own small engine in the Selenium core to support the following enhancements:
String getAllTableCellText(String uid)
Using Selenium core as the test driving engine is a quick solution for Tellurium, but it suffers some drawbacks such as low efficiency because Selenium core does not have built-in support for UI modules. Tellurium is developing a new engine to gradually replace the Selenium core in order to achieve the following goals:
|
Sign in to add a comment
