Selenium WebDriver - Test automation for web applications

Selenium WebDriver
Test automation for web applications

Thomas Sundberg
Stockholm, Sweden
Think Code AB
thomas@thinkcode.se
@thomassundberg
Blog: https://thomassundberg.wordpress.com/
Code: https://github.com/tsundberg/selenium-test-
automation/tree/luxsoft-january-2015
© Think Code AB, http://www.thinkcode.se

TESTING OF WEB APPLICATIONS

Testing of web applications
• Introduction to testing
• Manual testing
• Automated testing
• Selenium

Introduction
• Why testing?
• What to test?
• When to test?
• How to test?

Why testing?
• Create confidence to release

Why release?
• Create value
• Reduce waste
• Get feedback from real users
– Was this what they wanted?

Create value
• Using the software is the only way our
users/customers can benefit from our work
• This is the only reason why they pay us to
create it

Reduce waste
• Waste until it is used
• Unused code is waste
• Unreleased code is unused code
• Waste until it is deployed

Feedback from real users
• Is this was what they wanted?
• Release early
• Release often

When to test?
• As soon as possible

Why?
• Small problems are easy to fix
• Young problems are small
• Catch them before they grow up and become
big problems
– Large, old problems can be catastrophic

How to test?
• Manual
• Automated

Manual
• Always through the user interface
• Slow
• Inconsistent
• Doesn't scale
• Will find new, interesting bugs

Automated
• Different levels
– User interface
– Code
• Faster
• Consistent
• Scales
• Will never find new, interesting bugs

Manual vs. Automated
• Manual test
– Understand the problem
– Know the application
• Automated test
– Understand the problem
– Know the application
– Programming

SELENIUM

Browser automation
• Can be used for tests
• Doesn’t have to be used for testing

Where does the name come from?
• Selenium is a chemical element, Se
• Treatment for Mercury poisoning
• Mercury is a closed source web testing tool
• Selenium is a cure for Mercury

Tests
• Many frameworks
• Test NG
• Spock
• JUnit
• Others

Testing pyramid
End to end
Integration
Unit
Slow
Faster
Fast
Many reasons to fail
One reason to fail
Faster is better Fewer reasons to fail is better

End to end
• From the user interface
• Very slow
– It takes forever to start a browser and do
something
• Very fragile
– Lots of reasons why a test will fail
• The database is broken
• The user interface is missing a component
• Many more…

Doesn’t scale
• Impossible to test all paths
– 10 entrances from the ui
– 5 paths through the controller
– 7 paths through the model
– 10 * 5 * 7 = 350 paths
– 350 tests

Integration
• Verify that components works together
– Is the database properly configured?
– Is the queue started?
• Slow
• Fragile
– Many reasons to fail

Unit
• Small pieces of functionality at a low level
• Very fast
• Stable
– Only one reason to fail
– Failures are easy to understand
• Used for verifying all use cases for each
implementation
• Possible to verify all paths

Good tests
• Must be easy to
– Understand
– Maintain
– Change
– Extend

Inverted Testing pyramid
End to end
Integration
Unit
Slow
Faster
Fast
One reason to fail
Faster is better Fewer reasons to fail is better

Selenium echo system
• Selenium IDE
• Selenium WebDriver

Selenium IDE
• Firefox plugin
• Record and replay
• If you want to
– create quick bug reproduction scripts
– create scripts to aid in automation-aided
exploratory testing

Selenium WebDriver
• A programming framework
• Local in any browser you have installed
– Open source
– Anyone can use it
• Many programming languages
– We will use Java
• If you want to
– create robust, browser-based regression automation
suites and tests
– scale and distribute scripts across many environments

Selenium WebDriver
• W3C standard
– Not done, but well on its way
• Every W3C browser must support WebDriver

Selenium Hub
• Automate a browser remote
• Enable us to do cross browser testing
– Browser
– Operating system

WebDriver remote
• Same API as regular WebDriver
– If it works local, you can execute it remote
– SauceLabs

SELENIUM IDE

Hello, world!
• http://selenium.thinkcode.se
• Find an element and verify the text

Fill out a form
• Change password

WHAT TO TEST?

What should you test?
• Testing theatre
• Test stuff that matters

Security theatre
• Not aiming for security
• Aim to make people feel safe
• Security check on airports
– Why do they take you water bottle?
– If it is dangerous, remove it far away so it can't be
dangerous for you

Don’t test everything
• Enough to feel safe

Testing pyramid
End to end
Integration
Unit

User interface
• Do not test everything through the user
interface
• Test at the right level

End to end
• Can you login?
• Can you fail to log in?
• Can you do a purchase?
– At least place something in the shopping bag

Integration
• Connect to the database
• Connect to a queue

Unit level
• Password algorithm

You must be in control
• Collaborators
• Mock or Stub

Database
• Know about the content
• Decide what the content should be
• This makes End to end complicated

What should you automate?
• Any test that should be repeated
• At the right level...

What should you not automate?
• Expensive tests
– Buying using a credit card
– Probably enough to do one manual test
– Setup a fake server that mimics the payment
service
– http://wiremock.org

One off
• If it truly exists
• Automate it the second time

SELENIUM WEBDRIVER

First WebDriver test
• Export the code from Selenium IDE
– The code is ok
– Not pretty
– Ok to start with
• Good for finding elements

Browser tools
• Firebug
• Firepath
• Other favorites?

First handmade WebDriver test
• Hello world
• Without page object
• With page object

Hand made is better
• You have better control
• You know what you did
• Slower?
– Maybe at first, but not in the long run

Page objects
• Separation of navigation logic and test
– Only need to change the page object when the
layout changes
– The tests remain unchanged if the logic is the
same

Lazy
• Hard to solve a hard problem
• Better to solve many small

One class per page
• Abstracts the page functionality
• Hide the page navigation

Simplifies the tests
• The test focus on WHAT the application should
do
• Not on HOW
• Behavior is interesting

Supply the browser
• Through the constructor
– Allow you to use the same page object with
different browsers
• Verify that the current page is the right page
– Check title or similar characteristics
• Throw an exception if you can’t verify the
page

assertThat
• Signals through exception
• assertThat(actaulTitle, is(expectedTitle));

Example - Check boxes
http://selenium.thinkcode.se/selectColor.html

Test organization
By technology By functional area

Test organization
• Separate on functional areas
• Do not separate on technology
– A new developer want to find the relevant test
and page objects fast
• All tests and page object for a certain area
should live in the same package

Selenium echo system
• Selenium IDE
– Firefox plugin
• WebDriver
– Programming api
• Selenium hub
– Remote
– Different browsers
– Different operating systems

Test things at the right level
• End to end
• Integration
• Unit

End to end
• Verify that the system is alive
• Most crucial flow
– Buy a product
– Book a trip
• Very slow
• Lots of reasons to fail

Integration
• Slow
• Many reasons to fail
• Doesn’t scale

Unit
• Fast
• Only one reason to fail
• Algorithms
• Password

Testing theater
• Verifying important parts in the system
• Not for satisfying a managers metric

WebDriver
• close()
• findElement(By by)
• findElements(By by)
• get(java.lang.String url)
• getCurrentUrl()
• getPageSource()
• getTitle()
• getWindowHandle()
• getWindowHandles()
• manage()
• navigate()
• quit()
• switchTo()

Locators
• By.id(java.lang.String id)
– The preferred locater if the IDs are unique
• By.name(java.lang.String name)
– Almost as good as ID, if the name is unique
• By.xpath(java.lang.String xpathExpression)
– Depends on the page structure
• By.cssSelector(java.lang.String selector)
– Finds elements via the driver's underlying W3 Selector engine.
• By.linkText(java.lang.String linkText)
– Complicated if your site supports many languages
• By.partialLinkText(java.lang.String linkText)
– Complicated if your site supports many languages
• By.tagName(java.lang.String name)
– Probably not a unique element, all h1
• By.className(java.lang.String className)
– Finds elements based on the value of the class attribute.

WebElement
• clear()
• click()
• findElement(By by)
• findElements(By by)
• getAttribute(java.lang.String name)
• getCssValue(java.lang.String propertyName)
• getLocation()
• getSize()
• getTagName()
• getText()
• isDisplayed()
• isEnabled()
• isSelected()
• sendKeys(java.lang.CharSequence... keysToSend)
• submit()

Page objects
• Separate navigation and logic
• Clearer and easier tests
• Supply the browser
• Verify the correct page

Interested in more?
Join me in Timisoara, Romania in April for
A two day, in depth, Selenium course.
http://mozaicworks.com/public-trainings-and-workshops/selenium-webdriver-test-automation-for-web-applications/

Selenium WebDriver - Test automation for web applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Selenium WebDriver - Test automation for web applications

Similar to Selenium WebDriver - Test automation for web applications (20)

More from TSundberg

More from TSundberg (20)

Recently uploaded

Recently uploaded (20)

Selenium WebDriver - Test automation for web applications

Editor's Notes