24
Friday, November 5, 2010

"How Mozilla Uses Selenium"

Embed Size (px)

DESCRIPTION

My presentation at the November 3rd London Selenium Meetup, @ Google HQ

Citation preview

Page 1: "How Mozilla Uses Selenium"

Friday, November 5, 2010

Page 2: "How Mozilla Uses Selenium"

Friday, November 5, 2010

Page 3: "How Mozilla Uses Selenium"

London Selenium Meetup

Friday, November 5, 2010

Page 4: "How Mozilla Uses Selenium"

How Mozilla Uses SeleniumStephen DonnerNovember 3, 2010

London Selenium Meetup

Friday, November 5, 2010

Page 5: "How Mozilla Uses Selenium"

3

Friday, November 5, 2010

Page 6: "How Mozilla Uses Selenium"

Overview• Humble Beginnings

• First (Real) Cut at Automation

• Current Architecture (diagram)

• Hudson (Continuous Integration)

• Our Driver / TestRunner Implementation

• Thanks, Python+urllib

• Page Object Model

• The Future

• Questions?

3

Friday, November 5, 2010

Page 7: "How Mozilla Uses Selenium"

Humble Beginnings• All IDE, all the time

• Necessary evil, but painful• No scripted runs, inadequate reporting

• Graduated to RC

• Still uncoordinated, ad-hoc running• We all ran tests from the command-line• Still no great reporting/build history

4

Friday, November 5, 2010

Page 9: "How Mozilla Uses Selenium"

Current Architecture

6

Friday, November 5, 2010

Page 10: "How Mozilla Uses Selenium"

Hudson• Gives us:

• Reporting / notification• Email / status page / IRC

• Scheduling• Build history

7

Friday, November 5, 2010

Page 11: "How Mozilla Uses Selenium"

Our Driver / TestRunner Implementation

• Allows us to abstract code from core (driver)

• tests.py - list of smoke / bft / fft, etc. tests• consolidates all testfiles in one location, per-project • ability to tag tests:

8

Friday, November 5, 2010

Page 12: "How Mozilla Uses Selenium"

Our Driver / TestRunner Implementation

• suite.py - driver magic; uses Python’s unittest module– spawns a new, per-browser process– runs all tests in parallel among browsers– only time-bound by the longest-running test (/me glares at IE)

9

Friday, November 5, 2010

Page 13: "How Mozilla Uses Selenium"

Our Driver / TestRunner Implementation

• Running tests for specific features is as simple as:• python suite.py fft• python suite.py bft collections (logical AND operation)• etc...

10

Friday, November 5, 2010

Page 14: "How Mozilla Uses Selenium"

Thanks, Python+urllib• Staging servers down, much?

• Two ways of dealing with this:1. From suite.py:

2. From SUMO’s sumo_page.py:

11

Friday, November 5, 2010

Page 15: "How Mozilla Uses Selenium"

Page Object Modelpage.py

• Base class for ALL pages; most common functions (click, verify, etc.)

• Individual page classes derive from it

12

Friday, November 5, 2010

Page 16: "How Mozilla Uses Selenium"

Page Object Modelsumo_page.py

• All common elements of a SUMO page: log in/out, My Account, header/footer, etc.

13

Friday, November 5, 2010

Page 17: "How Mozilla Uses Selenium"

Page Object Modelsupport_home_page.py• Page elements are defined as class variables

• Operations that can be performed on the above are defined as functions

14

Friday, November 5, 2010

Page 19: "How Mozilla Uses Selenium"

Page Object Model• Benefits:

• Easy to read (and write) tests• Reduces the amount of duplicated code• Less ramp-up time for new testers + community• No more giant function files (distributed among pages)

• Caveats:

• All tests can now fail if a common element is broken• e.g..: AMO footer

• Multiple imports

16

Friday, November 5, 2010

Page 20: "How Mozilla Uses Selenium"

The Future• Projects in the POM where it makes sense (typically the case)

• Build-in screen / video captures of failures?

• Selenium 2; update our tests

• Native HTTP header manipulation?• (Specifically, user-agent/accept-headers)

17

Friday, November 5, 2010

Page 22: "How Mozilla Uses Selenium"

Questions?

19

Friday, November 5, 2010