Building frameworks over Selenium

5020510

Building frameworks over Selenium

Framework = ?Essential supporting structure of a building, vehicle or object

Why yes? Why not?

public static void main(String[] args) {WebDriver driver = new FirefoxDriver();driver.get("http://www.some-site.com");

System.out.println(“Opened the website!");

Thread.sleep(5);driver.quit();

}

#0Record & playAnti-patternsNo design

public static void main(String[] args) {

System.out.println(“Opened the website!");

Thread.sleep(5);driver.quit();

}

WebDriver driver = new FirefoxDriver();driver.get("http://www.some-site.com");Utils.openPage();

#1 Kickoff stageUtility classesOne big family

#1 Kickoff Stage IssuesDebugging time ~ test suite age

#1 LessonsLaw of Demeter is awesome

#2 – Localization challengeData providersData driven

Data driven+ Control behavior from outside+ Recycle existing tests - Tests have to get a bit smarter - Data providers can be complex

@DataProvider(name="SearchProvider") public Object[][] makeData(Method m){ if(m.getName().equalsIgnoreCase("testMethodA")){ return new Object[][] { { "Alpha", "Omega" }, { "A", "Z" } };

} else { return new Object[][] { { "A" }, { "B" }, { "D" } }; } }

@DataProvider(name="SearchProvider") public Object[][] makeData(ITestContext c){

for (String group : c.getIncludedGroups()) {//...

} }

#2 LessonsComplex stuff is made out of simple thingsHardcoded things suxData driven rulz

#2 Documentation!

#3 Performance TODO listReuse browser sessionsParallel tests

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd"><suite name="Parallel wall building" parallel="tests" thread-count="2">

<test name="T 1"><!--…-->

</test><test name="T 2">

<!--…..--></test><test name="T 3">

<!--…--></test>

</suite>

#3 PerformanceMulti-threaded tests

@BeforeMethodpublic void setUp() throws MalformedURLException {

threadDriver = new ThreadLocal<RemoteWebDriver>();

threadDriver.set(new RemoteWebDriver(/*...*/));}

public WebDriver getDriver() {return threadDriver.get();

}

#3 Performance pain pointsMultithreads and r/w global variables = no loveLogging is no longer that useful

#3 Lessons learnedDesigning is not optional

#4 Stability

#4 Stability pain pointsFalse-positives rateDebugging $ costsLack of trust

#4 Stability – baby steps improvement

1. Culture of stability2. Design patterns3. Make failures cheap

Lessons learnedRefactoring is inevitableUnit testing is not optional

#5 Harder, better, faster, stronger

#5 Trial of firePage objects

#5 Page objects

Home page

Shopping cart page

Contact form page

Page interface

#5 Trial of firePage objectsSmarter data providers

#5 Smart data providersData

provider

Data provider

FACTORY

Home page

Shopping cart page

Contact form page

Page interface

#5 Trial of fireSmarter data providersPage objectLoadable component

#5 Lessons learnedIncreased complexity must meanbetter documentation

#6 Mobile challengeWrite once, run everywhere

#6 Mobile challengeSupercharge page object

#7 GrowCustomer requests

PrinciplesThink ahead, work smarter

PrinciplesData driven

PrinciplesNothing is bullet proof

PrinciplesTest your tests

Thank you