Update: Before you continue reading, here is a new version of this test suite and article: Multi-Browser-Suite for Test Automation. It makes things a lot easier.
Have you heard of XLT Script Developer yet? If you have, you’ll probably agree that it’s a convenient tool to record and run automated test cases. However, with it being a Firefox plugin, you’re basically bound to run your test cases in Firefox. Wouldn’t it be nice to reuse Script Developer test cases in multiple browsers? You can actually do so by taking advantage of the WebDriver API that is part of the XLT framework.
If you don’t know much about WebDrivers, you should continue reading this article – the first one of a little article series on WebDrivers that hopefully gives you a good introduction to the topic.
WebDriver is a tool for automating web application testing that was originally introduced by Google. The API permits control of real web browsers, such as Firefox, Internet Explorer, Chrome, Safari, and the HtmlUnit headless browser.
Let’s start with the basics: How to use WebDrivers in the XLT context.
Script Developer test cases are stored in XML files. If you want to execute your test cases in multiple browsers, you need to run them as part of an XLT testsuite in your Java IDE, e.g. Eclipse. You can do so in two ways:
- Reuse the original Script Developer file (XML) within a JUnit wrapper class
- Export the test case to Java
Both options differ in the opportunities they offer: while the first one forces you to stick with Script Developer for test case editing and maintenance, the second option lets you make full use of Java.
If you go for the first option, select Generate JUnit wrapper class for test cases in the Script Developer Settings and you end up with a JUnit wrapper class for each test case.
You can now find this generated java class as part of your XLT testsuite in a folder defined by your Script Developer package structure.
In the following, this generated Java class needs manual editing. To prevent that your changes will be overwritten, uncheck “Generate JUnit wrapper class for test cases” because the wrappers are automatically regenerated after each modification in the related test case.
You can also make a copy of the wrapper class right after its creation and edit the copy. In that case, you don’t need to uncheck the checkbox after generating the wrappers.
The original wrapper looks like this:
|
1 2 3 4 5 |
@ScriptName ("com.xceptance.xlt.samples.tests.scripting.TBlogVisitor") public class TBlogVisitor extends AbstractScriptTestCase { } |
You can now execute the test by selecting “Run as JUnit test” from the Eclipse context menu of this specific file. By default, the XltDriver is used to run the test in a headless HtmlUnit-based browser.
Now, here comes the interesting part: to set your preferred WebDriver, add a constructor to the wrapper class. The example below makes use of the Chrome WebDriver:
|
1 2 3 4 5 6 7 8 9 10 |
@ScriptName ("com.xceptance.xlt.samples.tests.scripting.TBlogVisitor") public class TBlogVisitor extends AbstractScriptTestCase { public TBlogVisitor() { //Set WebDriver here super.setWebDriver(new ChromeDriver()); } } |
To make this work smoothly, you need to pay attention to the WebDrivers for Chrome and Internet Explorer. Download and install the driver files from the locations given above. Also make sure you’ve installed the latest versions of these browsers. Last not least, a system property setting is required right before calling the setWebDriver method.
Use this code line for Chrome:
System.setProperty("webdriver.chrome.driver",PATH TO DRIVER);
Use this one for Internet Explorer:
System.setProperty("webdriver.ie.driver",PATH TO DRIVER);
The placeholder PATH TO DRIVER has to be replaced with the location of the driver file. In Linux and MAC OSX systems, the path ends with /chromedriver, in Windows with /chromedriver.exe or /IEDriverServer.exe.
Pretty easy, isn’t it? But what about the second option? Why export test cases to Java code? The commands in Script Developer test cases are strictly sequential and thus may at times restrict your programming ambitions. If you want to take advantage of all the opportunities offered by Java, such as implementing loops, adding randomization, or forcing a conditional execution, you should convert your test case into Java code.
Right-click your test case or test package in Script Developer, choose “Export” from the context menu, select XLT Scripting API from the dropdown, and then confirm the export. Again, you’ll find the exported java class as part of your XLT testsuite in a folder defined by your Script Developer package structure.
An exported Java class looks like this:
|
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 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
public class TBlogVisitor extends AbstractWebDriverScriptTestCase { public TBlogVisitor() { super(new XltDriver(true), "http://example.com/"); } @Test public void test() throws Throwable { // // ~~~ OpenHomePage ~~~ // startAction("OpenHomePage"); open("/pebble/"); assertTitle("My blog"); assertElementPresent("link=>> Previous"); assertNotElementPresent("link=Next <<"); final Paging _paging = new Paging(); _paging.execute(); // // ~~~ ViewArticleDetails ~~~ // startAction("ViewArticleDetails"); clickAndWait("//div[@id='content']/div[1]/h1/a"); assertElementPresent("link=Send a TrackBack"); assertElementPresent("//div[@id='content']/div/div[3]/a[1]"); // // ~~~ AddComment ~~~ // startAction("AddComment"); click("//div[@id='content']/div/div[3]/a[1]"); type("id=commentBody", "A comment"); clickAndWait("//*[@id='commentForm']//input[@name='submit' and @type='submit' and @value='Add Comment']"); assertElementPresent("//*[@id='content']//p"); clickAndWait("name=submit value=Confirm"); assertElementPresent("//*[@id='content']//div[contains(@class,'contentItemBody')]"); // // ~~~ ReturnToHomePage ~~~ // startAction("ReturnToHomePage"); clickAndWait("link=Home"); assertTitle("My blog"); assertElementPresent("link=>> Previous"); assertNotElementPresent("link=Next <<"); } @After public void after() { // Shutdown WebDriver. getWebDriver().quit(); } } |
In the given example, the XltDriver is called by default (at line 5). You can change this into new InternetExplorerDriver() to use Internet Explorer WebDriver or one of the other available ones instead (Firefox, Chrome, Opera, iPhone, Android, Safari).
To help you understand the whole issue, the example below illustrates the complete procedure for the JUnit wrapper class, including the required imports, the property setting, and a useful way to automatically close the browser after test execution.
|
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 |
package com.xceptance.xlt.samples.tests.scripting; import org.junit.After; import org.openqa.selenium.chrome.ChromeDriver; import com.xceptance.xlt.api.engine.scripting.AbstractScriptTestCase; import com.xceptance.xlt.api.engine.scripting.ScriptName; @ScriptName ("com.xceptance.xlt.samples.tests.scripting.TBlogVisitor") public class TBlogVisitor extends AbstractScriptTestCase { public TBlogVisitor() { //Set driver path property here System.setProperty("webdriver.chrome.driver","C:/drivers/chromedriver.exe"); //Set WebDriver here super.setWebDriver(new ChromeDriver()); } //Automatically shutdown Web Driver after execution @After public void after() { super.getWebDriver().quit(); } } |
Now that you know how to run automated Script Developer test cases in all major browsers, you’re well prepared for the next part of this series: the challenges of test case design in different WebDrivers.
2 thoughts on “WebDrivers in XLT: How to Run Test Cases in Multiple Browsers”
Comments are closed.