DSL, Page Object and Selenium – a way to reliable functional tests

DSL, Page Object and Selenium – a way to reliable functional tests
Mikalai Alimenkou
http://xpinjection.com
26.02.2011

Background
Java Technical Lead/Scrum Master at Zoral Labs
6+ years in software development
4+ years of working by Agile methodologies
Expert in Agile engineering practices
Agile coach (TDD, Testing, Planning, etc.)at XP Injection (http://xpinjection.com)

Agenda
Selenium tests issues
Step 1: DSL introduction
Step 2: Page Object pattern
Step 3: Page Element pattern
Results analysis

Selenium TESTS Issues
When you have a hammer, everything looks like a nail

Test Components
Application Driver
Test Data
Test
Logic

How Selenium Works?
Get Browser
InvokeCommands
Provide Data
Use Locators

Selenium Tests Issues: Verbose
xpath=//input[@value=‘continue’]
browser.enter…
browser.click…
css=#results dip p.first
browser.getXpathCount…
id=greenButton
browser.waitForPageToLoad…
browser.check…

Selenium Tests Issues: Not Expressive

Selenium Tests Issues: Unreadable

Selenium Tests Issues: Fragile
browser.click("//input[@id=(//label[text()='Fax']/@for)] ");
What is going on here?
browser.getText(“//div[@id='App']/div/p[4]/div[1]/h4[@class='Online']”);
Depends too much on page structure!

Even More Hidden Issues

What is the Primary Goal?
To enable reliable stable tests we need to separate all parts as much as possible

Ideal Testing Framework
Test Data Storage
Technical Data Storage

Step 1: Introduce DSL
Create domain-specific language for your application

Definition of DSL
A domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, that is created specifically to solveproblems in this particular domain and is not intended to be able to solve problems outside it (although that may be technically possible).

DSL Usage Sample

Benefits of DSL Approach
High-level – tests are in the language of product management, at the user level
Readable – product management can understand them
Writable – easy for developer or QA to write new test
Extensible – tests base is able to grow with DSL

Tips and Tricks
Use test class hierarchy or test helpers
Use builders, visitors and other design patterns
Reuse domain model from application
Some common methods move to base test class
Minimize usage of browser instance in tests

Step 2: Introduce Page Object
Create page map for your application

Page Object Pattern
Index Page
order
search
Search Page
login
search
filter
Main Page
open
see more
Details Page
close
show me like this

Test Architecture with Page Object

Components Architecture
Isolated
logic
Concepts
separation
Easier support
Simplicity

Ways to Implement Page Object
Duplicate Site Map
with Packages and
Classes
Move Site Structure
to UI-Element

Tips and Tricks
Allow chain invocations
Basic page with browser details and common methods
Expose only what is allowed to see or do on the page
Don’t use browser instance in tests at all
Use static analysis to check rules
Use site map to prepare Page Objects

Step 3: Page Elements
Divide pages on reusable elements

Page Consists of Elements
Menu
Checkbox
Panel
Link
List of Items

Different Page Elements

Why Page Element Pattern?

Inversion of Control
Hides the details of browser communication
After
Before
Expose methods for what test can see and do

Tellurium Project

Tellurium Basics: UI Module
Groovy File
Can Build Xpath in Runtime
All Elements
Element UID
Isolated Locators
Available Actions

Tellurium Basics: UI Object
uid– unique in UI module
namespace – for future extension
locator – locator of the UI object
A base locator (relative XPath)
A composite locator (object attributes)
group – applied to some kinds of UI objects to switch on grouping locating
respond – define JavaScript events the UI object could respond to
some basic methods – isElementPresent, isVisible, isDisabled, waitForElementPresent, getText, mouseOver, mouseOut, getAttribute

Tellurium IDE and TrUMP

Tips and Tricks
Create elements when first need them
Review and improve elements continuously
Isolate and hide hacks inside elements
Use open source libraries as basis
Use annotations and other metadata techniques to simplify creation

Results ANALYSIS
What we have at the end of long way?

Long Way Bring Us to…
Reliable tests
Reusable test code
Separation of concepts
Expressive tested UI structure
Short and clear tests
Tests look more like acceptance tests
Tests are understood by non-technical people

Company DSL Library
Components may be reused between different applications and projects inside a company
AJAX Components
Company Portal
Basic Components
Online Store
JSF
Components
Customer Service

Any Questions?

http://seleniumcamp.com	5545
http://speakerrate.com	94
http://xpinjection.com	26
https://twitter.com	6
http://pinterest.com	4
http://translate.googleusercontent.com	4
http://www.onlydoo.com	1
http://webcache.googleusercontent.com	1
http://131.253.14.66	1
http://twitter.com	1
http://static.slidesharecdn.com	1
https://si0.twimg.com	1
http://67.207.142.125	1

DSL, Page Object and Selenium – a way to reliable functional tests

by Mikalai Alimenkou

Accessibility

Categories

Upload Details

Usage Rights

13 Embeds 5,686

Statistics

DSL, Page Object and Selenium – a way to reliable functional tests Presentation Transcript