ABOUT US

|

SUPPORT

|

BLOGS

 

 

DEVELOPER BLOG

 

 

 

 

 

 

 

Creating Data-Driven Functional Tests with LiquidTest

 

Mark Bayazit

 

 

 

 

 

Websites and web-applications have become technically complex, leading to a need for advanced automated test scripts that can validate their functionality. These scripts typically “walk through” a specific process and check to make sure certain actions and objects operate as expected. As the user provides different input into these web-applications, they change their behavior or present different datasets, prompts, or error messages, so it is not enough to simply run scripts with one set of values. Instead, the script needs to be able to run many different iterations of the same test, each with a different set of values. The ability to take actions (like entering text, choosing a radio-button, clicking a link, or validating returned content) dynamically is called parameterization, and a test that does this is often referred to as a “parameterized” or “data-driven” test.

This blog will provide a detailed description of how to use JadeLiquid’s LiquidTest tool to create data-driven functional test scripts for website/web-application testing. It will also show how to create asserts that validate functionality based on the specific parameterization data being used for a specific iteration of the test case.

Topics:

  1. Data-Driven Testing Guidelines – Some basic tips on how to design data-driven functional tests.
  2. Preparing To Create Some Test Scripts – An overview of how to get ready to create a script in a new, dedicated project.
  3. Data-Driven Test Example – An example of a data-driven test with dynamic assertions.

Data-Driven Testing Guidelines:

  1. Parameterization Effects – When you create a parameterized test, you should be aware of what the effect of parameterizing that input will be. Specifically, will each result page have the same form and objects or will the result page vary dramatically depending on the input value? For this example, we want to choose a website/web-application that will return pages that are essentially the same, but with different content, so that asserts (validation checks) that we make will work as expected. Future blog posts will show how to work with use-cases that cause different parameters to return vastly different web pages.
  2. Data Sets – You should identify which fields you will want to parameterize, and save some sample values in a spreadsheet column, with one row for each iteration of the test. You will also include any dynamic assert data in each row (in a separate column if it is different than your parameterization data). This is a very powerful mechanism to allow the asserts to reflect what was parameterized and allows for advanced tests with complex data-dependence.

Preparing To Create Some Test Scripts:

You might want to create a new project to hold the test cases that we will be creating in these exercises. Start LiquidTest, and click File->New->Project:

Select “Java Project” and click “Next”:

Provide a project name and click “Finish”:

Click “No” when asked if you want to open the Java perspective:

Before we create any new LiquidTest scripts, we should create a package (other than the default package), so click on the Package Explorer tab:

Right-click on the name that you specified when you created the project (here, I’ve used “Data-Driven Test Exercise”) and choose “New”->”Other”:

Select Package and click “Next”:

Provide a name for the package (with basic alphanumeric characters) and click “Finish”:

Data-Driven Test Example:
1. Data-Driven Test – For this data-driven test, we will use Wikipedia to search for several different terms. To start, we will create an Excel spreadsheet to store our parameters. Let’s create a column header “SearchTerms” to indicate what this column of data is for. We will use the same column for our dynamic asserts on each results page. If the assert data was different than the search term, we would add a new column of data for that. Note where you are saving the .xls file for later access. Here is an example of a spreadsheet I’ve created named “Parameters.xls”:

Now that we have our data ready, let’s create a test that will use it.

Create a new LiquidTest test. One way to do this is to right-click on the package you want to store the test in, such as the new package you created above, (or the src folder it is in, or the Project it is in) and select “New->LiquidTest Test”:

Pick your Test Case Writer according to the type of test you want to create. You can also set a default preference in LiquidTest preferences. Here I am selecting the JUnit 4 Writer. Provide a test name and click “Finish”:

If you left the “Start recording now” checkbox checked, then LiquidTest will start recording your test case. Depending on your established preferences, the “Getting Started with LiquidTest” page may show in the browser (but it will not be recorded into the script). You can simply enter the URL you wish to test into the address bar of the browser: in this case “www.wikipedia.org”, and press “Enter”:

The URL will load into the browser and we might want to assert to make sure the page came up correctly. Here I will verify that the Wikipedia logo, above the search text box, comes up correctly. Click “Lockdown and Inspect” button, then click the Wikipedia logo, then right-click it and select “Add Assertion”->”Assert Value”. You could also click on the logo and then use the DOM Inspector’s Structured tab, in the “Properties of Selected Node” section, to select which property of this object that we want to verify:

Now, we will get to the data-driven part of the test. Click on “LiquidTest Actions”->”Attach Datasource”, “Browse”, select the spreadsheet you created with the search terms for Wikipedia (my file was called “Parameters.xls”), and click “Open”, then click “Select”:

To parameterize the search box, click on the search box (it will be surrounded by a colored box, depending on your LiquidTest->Inspector->Border Color preferences), then right-click on the box to select “Bind Operation to Data Column”->”Column Name” (where column name is whatever you named the column for the data in the spreadsheet; mine is called “SearchTerms”):

The first data value you provided will be entered into the selected text box. You can now click “Unlock and Continue” and click on the search button (a right-arrow on the webpage) to execute the search in Wikipedia:

To verify that we received the correct page for our search term, I will add a dynamic assert for the title of the page, based on the parameter I searched for. Because the text content of the HTML object that displays the page heading changes for each page, you need to let LiquidTest know to search for the object as a Dynamic Element. Click the “Dynamic Element” checkbox on the LiquidTest Browser window.

Click “Lockdown and Inspect”, then click the “Tesla Roadster” title of the page (it is now surrounded by the selection color), then right-click it and select “Data Driven”->”Bind Assertion to Data Column”->”SearchTerms”:

We can now click “Unlock and Continue” and then “Finish Recording”. Our test now looks like:

To run the test case, right-click on the script itself (mine is called WikipediaSearchParameterized01.java) and select “Run As”->”JUnit Test”:

You will see the test case run once for each row of data that you provided in the spreadsheet (except for the column header you used). Here we can see the test completed three iterations and that each was successful (due to the green “check” mark indicated for each test iteration, shown in the JUnit tab):

If you’d like more time to observe the test as it runs, you can change the run speed by clicking the LiquidTest button pull-down arrow, and selecting “LiquidTest Preferences”:

To see the test as it runs, make sure the “Show Running Tests in Browser Window” checkbox is checked. You can vary the “Delay between Actions (ms)” field to slow down each action (such as typing, clicking a link, etc):

So we now have a test script that parameterizes both the data entered into a text box, as well as the data value that we validate on each result page.

Here is the actual script:

package datadriventestexercisepackage;

import static org.junit.Assert.assertEquals;

import org.junit.Test;
import org.junit.runner.RunWith;

import com.jadeliquid.liquidtest.Browsers;
import com.jadeliquid.liquidtest.DataDriven;
import com.jadeliquid.liquidtest.TestBrowser;
import com.jadeliquid.liquidtest.datadriven.MyData;
import com.jadeliquid.liquidtest.plugin.junit4.BrowserRunner;

/**
 * Recorded at 8/24/09 1:01 PM
 */
@RunWith(BrowserRunner.class)
public class WikipediaSearchParameterized01
{
   public TestBrowser browser;
   public MyData data;

   // Recorded by LiquidTest Developer v1.0.11 on Mon Aug 24 13:03:47 PDT 2009
   @Test
   @Browsers("MSIE7.0")
   @DataDriven("C:\\Parameters\\Parameters.xls")
   public void testMethod()
   {
      browser.load("www.wikipedia.org");
      assertEquals("", browser.getValue("174px-Wikipedia-word1_7.png"));
      browser.click("searchInput");
      browser.type(data.get("SearchTerms"));
      browser.expectingLoad().click("go");
      assertEquals(data.get("SearchTerms"),browser.getValue("/HTML/BODY/DIV/DIV[2]/DIV/H1"));
   }
}

 

 

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • StumbleUpon
  • Reddit
  • DZone
  • TwitThis
  • email
 Comments (0)

 

 


 

 

No comments yet

Add Comment..

 

 

About this blog..

 

This is an informal place for the team at JadeLiquid to discuss software, the rotation of the earth and other things usually discussed in the JadeLiquid corridors.

 

 

 

Subscribe: By Feed  By Email

 

 

 

 

 

Categories

 

 

JadeLiquid

LiquidTest

 

 

Software Testing

 

 

WebRenderer

 

 

 

 

Recent Posts

 

 

Selenium 2 / WebDriver support coming soon to LiquidTest..
Running Selenium Tests from the Command Line
LiquidTest 3.0 with Selenium support ships!
Setting up Atlassian Bamboo to run automated Web 2.0 tests
888 installer builds and 7469 code checkins later LiquidTest 2.0 ships!

 

 

 

 

 

Popular Posts

 

 

Testing complex Ajax content
Setting up LiquidTest with Subversion and Hudson (Continuous Integration) - part 1
Creating Data-Driven Functional Tests with LiquidTest
One tool to rule them all - Reducing team division
Setting up LiquidTest with Subversion and Hudson (Continuous Integration) part 2
Is manual testing crippling your development project?
Eclipse and LiquidTest UI Introduction
Protecting investment: Tests that do not break with page changes
Testing Dynamic Elements – Having a Plan B
Running Selenium Tests from the Command Line

 

 

 

 

 

Archives

 

 

May 2011 (2) April 2011 (1) November 2010 (2) March 2010 (1) February 2010 (1) November 2009 (1) October 2009 (1) September 2009 (2) August 2009 (1) July 2009 (1) June 2009 (1) April 2009 (1) March 2009 (1)

 

 

 

 

 
   News / Events

 

 > LiquidTest EOL Announcement - Info
 > LiquidTest Release 3.0! - Available
 > Visual Studio Plugin Released! - Release
 > Cruise Control .NET Integration - Info
 > Automate your Dev/Test Process - Webinar
 > Is manual testing crippling your project? - Blog
 > Testing complex Ajax content - Blog
 
 
   Recently Added Content  
 
 > Run LiquidTest's on Selenium RC/Server - Info
 > Setting up LiquidTest with Maven - Blog
 > Officially Supported Ajax Frameworks - Info
 > Atlassian Bamboo Integration - Tech
 > Setting up LiquidTest with SVN and Hudson - Blog
 > Creating Data-Driven Functional Tests - Blog
 > Reducing Test Maintenance - Blog
 
 
  Copyright JadeLiquid Software - 2013