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
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
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)
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!
From Series to Parallel• The solution? Use a dictionary. - Test names must be unique => Key - Each test has a test object => Value
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.
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