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, Server
Python, 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