Selenium
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
337
On Slideshare
337
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Selenium
  • 2. Overview• What is Selenium?• History of FT Tests• The current architecture• Parallelism• SQL• Web Driver
  • 3. Overview of Selenium
  • 4. Overview• Selenium has two pieces that make it run – Selenium Driver • Collection of Selenium commands that can be used to interact with the browser – Selenium Server • Processes the commands and executes them against the browser
  • 5. Visual representation Selenium Driver (C#, Selenium Firefox php, Ruby, ServerPython, Java)
  • 6. History of FT Tests
  • 7. A brief History…• In 2009, Portal was undergoing a re-skin.• There was 0 automation.• Matthew was tasked to find an automated tool. – Selenium vs Watin• Selenium won
  • 8. A brief History…• The architecture from 2009 is still serves as the foundation of how our tests run. – We have refactored sections of code, but the core of our tests has not changed.• Biggest change? – Tests are now broken up per application. – Each application has its own project. – This follows the way Hudson was designed by Jesse Dearing (I1) and Bryan Johnson (I2)
  • 9. Brace yourself. Code is coming.
  • 10. Parallelism
  • 11. From Series to Parallel• We were having execution time issues as the test suite grew. – Portal and InFellowship would take over 6 hours when we ran things locally.• Selenium has a problem when tests are ran in parallel – The instance of the selenium server would shut down for the wrong test!
  • 12. From Series to Parallel• The solution? Use a dictionary. - Test names must be unique => Key - Each test has a test object => Value
  • 13. Back to the code
  • 14. SQL
  • 15. Must go faster• The tests, now with parallelism, were still taking some time to execute. – This was becoming more of a problem with the increase demand for CI.• Too much set up of data in the UI – Groups and the wizards were the biggest culprit.
  • 16. Must go faster• Matthew started mocking things up via the DB. – If a test was to delete a resource, why mock it up through the UI?• Enter SQL
  • 17. Back to the code II
  • 18. Web Driver