Pankaj Nakhat's blog : All About Agile Testing

WebDriver is really  a good clean and powerfull API to test the browsers. Obviously now Selenium 2.0 is backed by WebDriver and there are different options you can use webdriver in different way. (With and Without a Proxy server) But originally WebDriver came with an idea of talking to browsers natively to driver then to achieve faster and better response. How is it different from Selenium. Please see the post . So, I would focus on this post to write a simple Google search test using webdriver.

I am assuming you have got a basic Java project setup where you can write tests in Java, and also you can choose any unit testing framework of your choice. WebDriver is a generic interface which then gets implemented by different available drivers (browsers) to achieve the consistency in the API. However, there are still some difference between the drivers, but we will ignore that for this posts, as basic API is consistent across the driver. Having an interface independent of driver implementation helps to write driver independent  tests, so we can write a test in WebDriver and run that against any available driver (Firefox, Chrome, IE and Iphone driver).

I must admit that chrome driver is little immature at the moment, but I am sure it should be good soon. For my example I will be using Eclipse as the IDE and TestNG as the unit testing framework.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package org.wd.tests;
 
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.Assert;
import org.testng.annotations.Test;
import org.wd.annotation.DataDriven;
 
public class TestGoogle{
 
	/* This creates a field of type WebDriver Interface*/
	protected WebDriver driver;
 
	@Test
	public void testGoogle(){
		/*This will crate a new Instance of Firefox driver*/
		this.driver = new FirefoxDriver();	
		/*This will launch www.google.co.uk on the browser*/
		driver.get("http://www.google.co.uk");	
 
		/*Identify the elements to interact with */		
		WebElement searchTextBox = driver.findElement(By.name("q"));
		WebElement searchButton = driver.findElement(By.name("btnG"));
 
		/*Take actions now - Set the text field*/
		searchTextBox.sendKeys("Pankaj Nakhat");
		/*Click on the searchButton*/
		searchButton.click();		
 
		/*Verify HTML response contains some text*/
		Assert.assertEquals(driver.getPageSource(), "Pankaj Nakhat");
		driver.quit();
	}
}

DSLs have been buzzing around for a while now, and I thought of putting some thoughts together.

DSL – Domain Specific Languages, what does it mean for Testing? What are the benefits..

Over the years automation testing has changed from record and play back mechanism to more structured, framework oriented approach. Benefits were evident Test were readable, Scalable and Maintainable.

But there was more needed to be done, as most automation tests would turn in to over head rather then assets.  Framework based approach was good..but came up with its own sets of problem. Some of them were Code like tests, which meant they were not human readable and needed either hours of

documentation to make them explicit to humans.  So if the application changed underneath both test and documentation needed to change. And after a while these will not match each other by any means.

Frameworks like keyword driven testing enabled naive to write Tests, however created the problem of highly non abstracted tests.

Since the introduction of methodologies like Agile, it was inevitable that those problem needed to be sorted fast. Tests needed to be changed quickly with often changing requirements.

DSLs allows you to write tests in your own domain..be it banking, Online Gaming or Travel Industry.  Which means tests are human readable and highly contextual to domain.

For example – I need to write a Test for a baking application for testing a Scenario of Transfer of a fund from Account A to Account B.  Note, I am talking in terms of any specific tool here, and that I will keep up for a separate post.

<Test>

1. Login in my online banking application with user “A”
2. Go to transfer funds page
3. Check initial balance it should be “£ 500″
4. Transfter amount “£100″ to account “B”
5. Check final balance , it should be “£ 400″
6. logout from the application.

</Test>

In above example , Test exactly looks like manual test scripts but there nature is Executable in whatever technology and tool we choose.

What problems does it solve?

• Maintenance is easier now as test are human readable.
• Adding and Amending a step in Test just requires finding the right step, rather then changing the implementation  (In Most of the cases).
• For example – In above Test I need to add a new requirement of a welcome page after login. We simply introduce another DSL step after step1 “Verify user is shown welcome page with him name on it”, and rest of the test is still unchanged.
• Test can be extended easily to do more comprehensive end to end test.
• If the application changes underneath in terms of UI Objects , tests will remain unchanged, only the underlying implementation will change.
• If a business process changes completely, changed can be accommodated easily by changing the DSL definition. For example in above Test the transfer process changes and now required another level of authentication before transferring the funds. We would change the definition of Step4 to ‘Transfter amount “£100″ to account “B” and enter authentication password for user “A”‘

DSLs can also come with its own challenges, which I would like to discuss in my next post.

[quicksubscribe]