Download to read offline
Uploaded byBryan Mikaelian
Selenium
This document provides an overview of Selenium, including: - A brief history of how automated functional tests have evolved over time at the company from having no tests to utilizing Selenium. - An explanation of the current Selenium architecture used by the company's tests, including how tests are now broken up per application to follow the way the continuous integration server was designed. - Details on how parallelism was implemented in the tests to address execution time issues as the test suite grew, including the use of a dictionary to ensure unique test names. - How SQL was incorporated to speed up tests by mocking data setup directly in the database rather than through the UI to reduce lengthy wizard and group creation times.
More Related Content
![Selenide alternative in Python - Introducing Selene [SeleniumCamp 2016]](https://cdn.slidesharecdn.com/ss_thumbnails/seleniumcamp2016-selenidealternativeinpython-introducingselene-160226140611-thumbnail.jpg?width=640&height=640&fit=bounds)
Selenium
- 1.
- 2. Overview • What is Selenium? • History of FT Tests • The current architecture • Parallelism • SQL • Web Driver
- 3.
- 4. Overview • Selenium hastwo 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, Server Python, Java)
- 6. History of FTTests
- 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. Codeis coming.
- 10.
- 11. From Series toParallel • 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 toParallel • The solution? Use a dictionary. - Test names must be unique => Key - Each test has a test object => Value
- 13. Back to thecode
- 14.
- 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 thecode II
- 18.