Presentation slides available in link
Notes from the talk
Design Decisions
- Build common framework
- Isolate Test Case specific details
- Application specific logic kept in client class
- Provide uniform way of accessing UI elements
- Flexibility - Group Test Cases
- Placeholder for configuration data
- Maintainability - Maintaining Data for Testcases
- Support Data Driven Test, Same test run with different sets of data
Architecture
- Tool Selection Criteria - Handle AJAX Controls
- Selenium Locators - Identify element in page
- Testing Framework - TestNG
- Data provider features- Support for Data Driven Testing
- TestNG would handle looping and invoking methods
- Read from XML, Database is supported
- Firebug - Used as Development Tool
Architecture
- Configuration Layer
- UI Layer Abstraction
- Application logic lies in client class
- Uniform way of accessing UI object using helpers
- UI Map - Storing UI Elements
- Data could be shared acrosss Test Cases
- Keep data in one place
- Web Apps Common Action - Filling forms
- Helper class takes page & data object
- For each UI element fill corresponding provided values
- Changes is updating UI & Datamap
- Application Client - Subtree of classes
- Contains Test cases, Uses API's provided by client class
- Test Case Flow - Test Case -> Client Class (High level API) -> Helper (Common actions, Wrapper classes using selenium commands)
More Reads - Link1, Link2
Selenium - is NOT a Framework
Template method pattern
Selenium 2 Examples
Web test automation best practices
First steps with Lightweight Test Automation Framework
Selenium Framework by Google