Creating Data-Driven Functional Tests with LiquidTest

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.
  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 “”, 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 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:
  1. package datadriventestexercisepackage;
  2. import static org.junit.Assert.assertEquals;
  3. import org.junit.Test;
  4. import org.junit.runner.RunWith;
  5. import com.jadeliquid.liquidtest.Browsers;
  6. import com.jadeliquid.liquidtest.DataDriven;
  7. import com.jadeliquid.liquidtest.TestBrowser;
  8. import com.jadeliquid.liquidtest.datadriven.MyData;
  9. import com.jadeliquid.liquidtest.plugin.junit4.BrowserRunner;
  10. /**
  11. * Recorded at 8/24/09 1:01 PM
  12. */
  13. @RunWith(BrowserRunner.class)
  14. public class WikipediaSearchParameterized01
  15. {
  16. public TestBrowser browser;
  17. public MyData data;
  18. // Recorded by LiquidTest Developer v1.0.11 on Mon Aug 24 13:03:47 PDT 2009
  19. @Test
  20. @Browsers("MSIE7.0")
  21. @DataDriven("C:\\Parameters\\Parameters.xls")
  22. public void testMethod()
  23. {
  24. browser.load("");
  25. assertEquals("", browser.getValue("174px-Wikipedia-word1_7.png"));
  27. browser.type(data.get("SearchTerms"));
  28. browser.expectingLoad().click("go");
  29. assertEquals(data.get("SearchTerms"),browser.getValue("/HTML/BODY/DIV/DIV[2]/DIV/H1"));
  30. }


이 블로그의 인기 게시물

Android Service에서 AlertDialog 띄우기

MongoDB, 설치와 간단 사용법

Android Thread 내에서 UI 핸들링