Web Application Testing with Selenium for DynDNS.com

Selenium Seminar  Cory von Wallenstein  February 12, 2009 

Overview  • What is Selenium? What is it not?  • Selenium as a support and bug‐report tool  • High‐level best pracCces  • Under the hood of our implementaCon 

UnigressificaConal TesCng  • Terms I use, exact definiCons debatable  • Unit tesCng  – “Test one thing in isolaCon”  • Regression tesCng  – “Test one thing that broke”  • FuncConal tesCng  – “Test things working together”  • VerificaCon tesCng  – “Test all of the things working together” 

What’s the problem? I want to…  • Test the code  • Test that the code produces a web page  • Test the content on the web page  • Test the semanCc meaning of the content on the  web page  • Test the display of the form that is below the  content on the web page  • Test the display of the form that is above the  content on the web page 

What’s the problem? I want to…  • Test the submission of the form with invalid data  such that an error is displayed above the form  (server side validaCon) and the form is above the  content on the web page.  • Test the submission of the form with invalid data  such that an error is displayed above the form  with client side validaCon if the client has  JavaScript and server side validaCon if not and the  form is above the content on the web page.   

What’s the problem? I want to…  • Test the submission of the form with invalid data  such that an error is displayed above the form  with client side validaCon if the client has  JavaScript and server side validaCon if not and the  form is above the content on the web page, except  for IE6, where the form error displays below the  form.   

What’s the problem? I want to…  • Test the submission of the form with invalid data  such that an error is displayed above the form  with client side validaCon if the client has  JavaScript and server side validaCon if not and the  form is above the content on the web page, except  for IE6, where the form error displays below the  form. for Firefox, Safari, Opera, and IE7, but  display a message for IE6 users telling them to  switch browsers.   

What’s the problem? I want to…  • Test the submission of the form with invalid data  such that an error is displayed above the form  with client side validaCon if the client has  JavaScript and server side validaCon if not and the  form is above the content on the web page, except  for IE6, where the form error displays below the  form. for Firefox, Safari, Opera, and IE7, but  display a message for IE6 users telling them to  switch browsers and make sure *nix users get a  virtual high‐ﬁve when they submit the form.   

What’s the problem? I want to…  • Make sure it all sCll works six months from now  when I forget what the heck this form was  supposed to do. 

Take a look at Selenium.  h'p://seleniumhq.org 

What is it not? 

Selenium Architecture  • Record workﬂows  • Interact with content displayed in the browser in a  fairly robust way  • Create tests from workﬂows in the language of  your choice  • Same test code can be browser and OS agnosCc  • Built‐in remote control and grid funcConality 

Selenium IDE  • Firefox Plugin  • Record workflows  • Play back workflows  • Exchange workflows  • A good starCng point for test code 

Best PracCces 

High‐level Best PracCces  • The IDE generated code is garbage, but you fully  expected that. :‐)  • Very dependent on screen scraping  • Very dependent on element nesCng  • SuscepCble to Cming issues  • But it’s a good starCng point for learning!  • (Brush up on your Xpath) 

Goals for Selenium TesCng  • If stuff moves around, but the funcConality is  there, the test should not break nor require  modificaCon.  • If content is changed, but the funcConality is  there, the test should not break nor require  modificaCon.  • If your network is latent or your computer is under  load, the test should not break. 

Use Speciﬁc DOM IDs  • Trouble: //div[@id='sidenav‐content']/table[1].0.2  • Less trouble: //div[@id=’bu;on_next’]   • Design for test  • ID is unlikely to change (if you have a good naming  scheme!)  • Move item to test anywhere on page; across pages  • Easy to separate “is it there?” from “does it  contain what I expect it to?” 

Avoid String Matching  • Trouble in scraping screen for string:   An error occurred. Sorry. Tough noogies.  • Less trouble in checking presence of element:  //label[@for='username' and @class='error']  • Use the DOM agributes as much as possible.  • Match long strings as ligle as possible.  • Best kept to keywords… does element contain:  – “required”, “order failed”, ”error”  

Is The Page Ready To Test?  • Built‐in “is page done loading” method less than  perfect.  • Look for something on the page  – Header  – Footer  – Ajax – No swirly icon 

Go Higher Level  • Start refactoring into higher level methods sooner  rather than later  • Common ones:  isPageReallyReady  – clickAndWait  – createNewAccount  – login  – assertBlahAndCaptureScreenshot  – populateFormAndAssertDataAppearsInDatabase  –

Go Higher Level  • Organize base classes around workflows  – Why? Common test fixtures!  • Common fixtures:  – Tests requiring an account  – Tests requiring no account  – Tests requiring signing up for an account  – Tests requiring a paid for item  – Tests requiring data to display that is difficult to  produce 

Make Changes Easy  • Organize unit test classes/ﬁles around URIs  • Edge case tesCng  • Data validaCon  • Logged in versus logged out 

Make Changes Easy  • Organize funcConal test classes around workﬂows  • Create an account (mulCple steps)  • Buy something  • RMA/cancel something  • Provision something  • Thing 1 interacts with Thing 2 

Plan for Failure  • Keep unit, regression, funcConal, and veriﬁcaCon  tests separate  • Ideal is funcConal test failed, and a unit test told  you exactly what caused the failure  • Or a funcConal test failed, and a regression test  told you you’ve seen this bug before  • No debugging necessary 

Plan for Failure  • Keep unit, regression, funcConal, and veriﬁcaCon  tests separate  • Shorten Cme between failure creaCon and failure  discovery.  • Run test suites at diﬀerent frequencies/events. 

Avoid Workﬂow Overlap  • Do as much setup behind the scenes as possible  – Create an account in the database rather than form  – Add an order item in the database…  – Etc.  • Aim to test just a single “thing” per test case  • Refactor prerequisite workﬂows to base classes 

Selenium is Slow  • Rare to have a test case execute in less than 5‐10  seconds.  • Clean browser for each test case. IsolaCon.  – Human Cme more valuable than machine Cme.  • Plan accordingly.  • Open exasperated by external dependencies and  systems… 

Mock up! Unplug!  • Everything but a veriﬁcaCon test should use  mocking  • Mocking  – Mock behavior of external system in a fast and  reproducible way  – Example: DynDNS.com and credit card processor  – Be able to reproduce speciﬁc error responses!!!   – Anyone can make something that works on success.  Our job is to make it work on parCal failure.  

http://www.standingonthebrink.com	231
http://www.slideshare.net	13

Web Application Testing with Selenium for DynDNS.com

by Dyn on Feb 16, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 244

Statistics

Web Application Testing with Selenium for DynDNS.com — Presentation Transcript