JadeLiquid Blog

Selenium 2 / WebDriver support coming soon to LiquidTest..

dthomas — Tue, 24 May 2011 03:51:11 +0000

Coming soon to LiquidTest is a full featured Selenium 2 / WebDriver recording engine within the IDE, supporting both Internet Explorer and Firefox. Watch our sneak peek video..

Running Selenium Tests from the Command Line

Anthony Scotney — Wed, 04 May 2011 00:06:36 +0000

Running Selenium tests from the command line on Windows 7 can be slightly challenging simply due to the permissions system. By default Windows 7 tends to be locked down and there is conflicting information out there on exactly what steps to take to get Selenium tests running. The intention is that this article will provide some help for people trying to run Selenium Test Suites from the command line on Windows 7 (and other Windows versions).

1) Create a Selenium HTML test

Create a simple Selenium test (or ten) to add to your test suite. Creating a Selenium test is easy in LiquidTest. See our LiquidTest documentation on “how to record Selenium HTML tests“.

2) Create a Selenium Test Suite

Because HTML is essentially a content formatting language it contains little scope to tell any executing program exactly what to do outside of basic presentation. With this in mind and given that Selenium supports the HTML test format, the Selenium team came up with Selenium Test Suites to tell the Selenium runner (Selenium RC/Server) what tests to execute and the order of execution. Selenium Test Suites are fairly straight forward. In their simplest form they contain an HTML Table (TABLE), with a Row (TR) and some Table Data (TD).


	
		My Application Test Suite
	
	
		
			Suite Of Tests
			Test Example

Notice that the tests can be grouped with the first Table Row, and then the preceding rows link to the actual test cases. This formatting helps with both execution ordering of test cases and to attach meaningful data to the results file output by the Selenium RC/Server.

3) Executing Selenium Test Suites from the Command Line

Security and Internet Explorer: Due to Windows 7 security, running tests as anything but Administrator produces sketchy results at best. I had numerous problems with Internet Explorer. Firstly Internet Explorer was loading Selenium RC/Server with many script errors regardless of configuration. The tests never replayed in this state. Firefox fared better in that it ran and produced the necessary results file. To avoid security issues with Selenium RC/Server ensure that any tests you are executing from the Command Line are through an Administrator Command Prompt (right-click on the Command Prompt and select “Run as Administrator”.

Creating a Windows Batch file to run your Selenium Test Suite
To make life a little easier we will create a simple batch file to save writing the command out by hand for each Selenium Test Suite execution. The batch file consists of Java’s JAR command (ensure Java is in your System PATH or use the full file location to your Java bin directory). We specify to Selenium RC/Server that we wish to run a Test Suite, targeting Internet Explorer with a default URL of google.com (for our test) and then we specify where our Selenium Test Suite is located, where we want our Results file written and finally the Port for executing the communication.

java -jar selenium-server-standalone-2.0b3.jar -htmlSuite "*iexplore" "http://www.google.com" "D:\selenium-2\TestSuite.html" "D:\selenium-2\results.html" -port 4445
pause

The action..
When running a Selenium Test Suite, the browser you’re targeting will open and the test will replay.

4) Selenium test execution Results File

Selenium will start up and execute the Test Suite and write a Results file to the location you specified. The Results file looks like the following:

Hopefully this example will be enough to get you started with running your Selenium HTML tests from the command line. For information on how to run your Selenium JUnit tests against the Selenium Server from within the Eclipse IDE please view the tutorial here..

LiquidTest 3.0 with Selenium support ships!

dthomas — Tue, 12 Apr 2011 03:51:38 +0000

By now you have probably seen our press release about Selenium support in LiquidTest. If not you can see it here. No doubt you will have a few questions about this so I thought I would try and answer some for you:

What do you mean Selenium is now supported?
LiquidTest can now Record (in IE and Firefox) tests and write them in either Selenese (Selenium HTML) or Selenium JUnit. These tests will work within either LiquidTest or the standard Selenium infrastructure.

LiquidTest can also replay Selenium tests. So if you have a lot of these already you can bring them into the LiquidTest environment.

Why did you do it?
Selenium is a very popular testing framework. The Selenese language is almost a standard in the “developer tester” field. So adding support for this wasn’t too much of a leap. The problem Selenium has is that in order to test complex web applications, you need to have a developer’s understanding of both the application and of writing code for Selenium. In other words, you need to be a Developer.

You could try using the Selenium IDE Recorder, but it has many limitations when it comes to recording complex applications.

Selenium for the Masses!
By using LiquidTest, any user who has the ability to use a browser can start creating tests in Selenium! Point and click, and your Selenium test is created. Replay it and watch it work. And we aren’t just talking basic tests. Complex web applications making use of Ajax frameworks can now have tests created for Selenium using the LiquidTest recording engine.

By coupling LiquidTest’s robust record and replay engine with Selenium’s ubiquitous language, testing your application just got a lot easier. And hopefully we can bring more people into the Selenium testing world.

But LiquidTest is also great for experienced Selenium developers. Being able to develop your Selenium Tests in the Eclipse environment, access DOM and XPath information as you create your tests, manipulate your tests using a Data-Driven approach as well as run your tests in a headless environment which all combine to make this a powerful tool for developers as well.

Anything else I need to know?
We have added a few features as well, not just the industry’s leading record and replay engine. How about a few of these goodies now supported in Selenium:

Record Selenium tests with Internet Explorer

DataDriven tests in Selenium
Multi Domain support
Pop up windows supported
Supported Ajax Frameworks
Intelligent Object identification

To name just a few..

If you would like to try it out venture over and visit the home of our Selenium support to download a free trail:
http://www.jadeliquid.com/liquidtest/docs/doku.php?id=general:selenium:home

Setting up Atlassian Bamboo to run automated Web 2.0 tests

dthomas — Tue, 16 Nov 2010 04:20:39 +0000

One of our Developers put together the following document on how to get Atlassian’s Bamboo up and automating LiquidTest test suites. Here it is..

Bamboo™ is a Continuous Integration server by Atlassian™. Continuous Integration is a development practice where software developers integrate their work frequently. Each integration is then verified by an automated build to detect errors as quickly as possible.

LiquidTest™ is an agile Web Application Testing tool with an integrated Record and Replay engine powered by Firefox™ and Internet Explorer™. LiquidTest supports industry standard languages (Java™, C#, Visual Basic .NET and Groovy) and integrates with IDE’s and Continuous Integration servers.

This document will walk you through downloading and configuring Bamboo and LiquidTest so that Bamboo will execute a LiquidTest build and verify recorded tests automatically.

I have cut out the setup of a Linux box or Subversion repository, so the following assumes you already have a working Subversion repository containing an example LiquidTest Project (Use the Hudson setup blog post as a starter guide available here).

Bamboo is available for Windows/OSX/*nix, and can be downloaded from Atlassian’s website.

Installing Bamboo

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -
cd /opt
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -

Get latest stable version of bamboo, as of this writing it’s 2.5.1

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -
wget

http://downloads.atlassian.com/software/bamboo/downloads/atlassian-bamboo-2.5.1-standalone.tar.gz

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -

Extract the distribution files

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -
tar zxf atlassian-bamboo-2.5.1-standalone.tar.gz
cd Bamboo
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -

Edit the bamboo-init.properties file and set the bamboo.home variable to be /opt/Bamboo

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -
sudo nano webapp/WEB-INF/classes/bamboo-init.properties
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -

Now launch the server via the shell script:

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -
sudo ./bamboo.sh start
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -

Now you can browse to http://:8085/ (if you need to discover the IP, just type ifconfig)
You should be prompted for a license key:

Follow the “Contact Us” link which will take you to an Atlassian site to register for a trial key.

You will then be able to copy your trial key and paste it back into the Bamboo welcome screen.

Hit Express Installation…

You will be prompted to create an administration account;

Click finish…

Now we need to create a plan.

Create a new plan

Project Name: LiquidTestIntegrationExample
Project Key: LTIE
Build Plan Name: Default
Build Plan Key: DEF

Hit next.

Specify Source Repository

In the Repository type drop-down, select Subversion.

The URL should be http:///svn/LiquidTestProject/

Set the Build Strategy to “Polling for changes.”
Set the polling frequency to be 180 seconds.
Hit next.

Choose a Builder

Now we need to configure a builder.
Hit add new builder.

Add New Builder

By default we won’t have any version of ant installed, so we need to configure it with the version we installed earlier.

Hit add.

Now we have some ant properties we can set:-

Build File should be “build.xml”
Target should be “runtests”
Build JDK: Just use the default JDK it detects.

In “Where should Bamboo look for the test result files”
check “The build will produce test results”
with a pattern of: */build/log/.xml

Hit save.

Bamboo should now build the project and execute the tests.

Congratulations, you can now commit changes to the Subversion repository, and Bamboo will detect new revisions and automatically build and run your LiquidTest tests.

To see more LiquidTest integrations visit our Itegrations home..

888 installer builds and 7469 code checkins later LiquidTest 2.0 ships!

Anthony Scotney — Fri, 05 Nov 2010 00:18:10 +0000

We have shipped! Sincere thanks to all those that have waited patiently for our LiquidTest 2.0 to ship. The official release information is as follows:

Web Application Test Automation just got a whole lot easier
JadeLiquid Software, developers of LiquidTest, the Web 2.0 application testing framework designed for developers, announced the release of LiquidTest 2.0. LiquidTest 2.0 is stacked with new features including new IDE integrations, languages and massive core engine improvements. LiquidTest now ships with specific support for Web 2.0 frameworks such as ExtJS, Dojo, GWT, ASP.NET and more.

LiquidTest 2.0 – defined
* The Industry’s leading Web Testing Engine
* Robust XPathing and object recognition for greater test stability
* Platform support including Java (Eclipse) and Microsoft Visual Studio .NET
* Multiple browser support (Internet Explorer and Firefox)
* Compatibility with Web 2.0 frameworks
* File Upload and Download support
* Support, support, support – you find it, we fix it right away!

Ready to turn the agile web testing world upside down
LiquidTest 2.0 is the accumulation of 2 years of closed-doors development with select LiquidTest clients with the aim of perfectly “tuning” the internal LiquidTest engine. Throughout this process the XPathing, Rule Matching and Framework Compliance engines have undergone ground-up rebuilds all in the name of making LiquidTest the best Web Application Test tool out there. With these major changes LiquidTest is a completely different animal to LiquidTest 1.0 or any other Web Application Testing tool ever developed.

Less time fixing, more time running tests
Traditional testing frameworks struggle when it comes to the current generation of Web technologies. LiquidTest is ground-up engineered to support the most complex of Web 2.0. Under the hood, LiquidTest utilizes deep hooks into real browsers (Firefox and Internet Explorer). These deep hooks allow LiquidTest to record your actions, monitor page events and reactions and create succinct, robust test cases in languages you are already using.Check out our compliance with your framework of choice on our Supported Web 2.0 Frameworks page.

Documented Integrations, Integrations, Integrations
LiquidTest is designed to fit into your development environment. The LiquidTest team has been continuously writing and releasing integrations with many popular tools and frameworks.

Below are some of the LiquidTest integrations:
- Build Tools: ANT, Maven, NAnt, MSBuild
- Continuous Integration: Hudson, Atlassian Bamboo, Cruise Control .NET
- IDE’s: Eclipse, Visual Studio
- Test framework support: JUnit, TestNG, NUnit
- Language support: Java, Groovy, C#, Visual Basic
- Framework support: ExtJS, Dojo, GWT, ASP .NET

Setting up LiquidTest with Maven

hirving — Thu, 04 Mar 2010 06:22:08 +0000

One of our Developers put together a nice Maven Integration document that will go out with our website refresh later this month. Given the popularity of Maven, I thought I would share it before the site-refresh goes live!

Install Maven

This guide assumes you already have Java and Maven 2 installed. If you don’t have Maven, you can follow the installation instructions on the Maven website.

Open a command prompt with access to Maven so that you can follow the rest of the instructions in this guide.

Install LiquidTest into your local Maven repository

Maven projects cannot depend on JARs that are not Maven artifacts, which means that you can’t just drop LiquidTest into your classpath as you would with other build systems. Instead you’ll need to install LiquidTest into your local repository so that Maven can see it and your tests can depend on it.

Suppose you’ve obtained liquidtest-nodeps-1.0.17.jar and you’d like to tell Maven about it. Run the following command in the same directory as the JAR file:

$ mvn install:install-file \
      -Dfile=liquidtest-nodeps-1.0.17.jar \
      -DgroupId=local.jadeliquid.liquidtest \
      -DartifactId=liquidtest-nodeps \
      -Dversion=1.0.17 \
      -Dpackaging=jar

If you understand how to use private Maven repositories, you can manage your LiquidTest JARs centrally instead of installing them manually on each workstation/server.

Package and install you LiquidTest license key

LiquidTest looks for its license key and other configuration parameters in a liquidtest.properties file on its classpath. There are a few ways to achieve this, but one of the simplest is to add your configuration to its own JAR and install it into Maven’s local repository.

Start by creating your liquidtest.properties file. It should contain at least the following line:

licenseKey=

You can add other LiquidTest configuration properties if you like.

Be sure to use your actual license key instead of the placeholder, or LiquidTest won’t run!

Now, add your properties file to its own JAR archive with the following command:

$ jar -cvf liquidtest-properties.jar liquidtest.properties

The final step is to add this JAR to your repository as you did with LiquidTest itself:

$ mvn install:install-file \
      -Dfile=liquidtest-properties.jar \
      -DgroupId=local.jadeliquid.liquidtest \
      -DartifactId=liquidtest-properties \
      -Dversion=1.0-SNAPSHOT \
      -Dpackaging=jar

Create a Maven project

If you don’t already have a Maven project, you’ll need to create one by entering the following:

$ mvn archetype:create \
      -DgroupId=com.example.myproject \
      -DartifactId=my-project

This will create a skeleton project in the my-project/ directory. You can replace the group and artifact IDs with something more suitable for your project.

Add the FailSafe plugin for integration testing

The FailSafe plugin is used for integration testing in Maven. To use it, add the following to your project’s pom.xml:


  [...]
  
    
      
        org.codehaus.mojo
        failsafe-maven-plugin
        2.4.3-alpha-1
        
          
            integration-test
            
              integration-test
            
          
          
            verify
            
              verify
            
          
        
      
    
  
  [...]

You can find more information on FailSafe at http://mojo.codehaus.org/failsafe-maven-plugin/usage.html.

Add LiquidTest dependencies

Add these dependencies to your project’s pom.xml so that the integration-test phase can use LiquidTest to run your tests:


  [...]
  
    [...]
    
      local.jadeliquid.liquidtest
      liquidtest-nodeps
      1.0.17
      integration-test
    
    
      local.jadeliquid.liquidtest
      liquidtest-properties
      1.0-SNAPSHOT
      integration-test
    
    [...]
  
  [...]

Update the JUnit dependency to JUnit 4

Maven’s default project configuration uses JUnit 3, which is no good if you’re using LiquidTest to generate JUnit 4 test files. Luckily this is easy to fix: find the JUnit 3.8.1 element in your pom.xml and replace the version number with a more suitable one. You can specify a particular version of JUnit with 4.3.1, or request any version of JUnit 4 with [4.0,).

You will also need to add JUnit to the integration-test lifecycle phase. To do this, replace test with test integration-test.

Here's how your project's configuration should appear after making these changes:


  [...]
  
    [...]
    
      junit
      junit
      [4.0,) 
      test integration-test 
    
    [...]
  
  [...]

Enable support for Java 5 constructs

Maven uses Java 1.3 syntax by default, which is no good if you want to compile JUnit 4 tests with annotations. To remedy this, explicitly set the Java source and target versions in the compiler plugin's configuration using the following code:


  [...]
  
    [...]
    
      [...]
      
        org.apache.maven.plugins
        maven-compiler-plugin
        
          1.5 
          1.5 
        
      
      [...]
    
    [...]
  
  [...]

If you want to use Java 6 language features, you'll need to write 1.6 instead.

Add LiquidTest tests to your Maven tree

By default, FailSafe will look for test files using the pattern **/*IT.java. Create a test file with a name ending in IT and add it to your project's src/test/java/ tree at the appropriate package location.

For example, this test script would be placed at src/test/java/com/example/myproject/SampleIT.java:

package com.example.myproject;

import static org.junit.Assert.assertEquals;

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

import com.jadeliquid.liquidtest.Browsers;
import com.jadeliquid.liquidtest.TestBrowser;
import com.jadeliquid.liquidtest.plugin.junit4.BrowserRunner;

@RunWith(BrowserRunner.class)
public class SampleIT
{
	public TestBrowser browser;

	@Test
	@Browsers("Firefox2.0")
	public void rfcHref()
	{
		browser.load("example.com");
		assertEquals("http://www.rfc-editor.org/rfc/rfc2606.txt",browser.getNodeAttribute("//*[text()='RFC \n  2606']", "href"));
	}

}

Run your tests in Maven

Now that everything is set up, you should be able to invoke Maven to run your LiquidTest integration tests:

$ cd my-project
$ mvn verify

Once Maven has downloaded any needed dependencies it will use LiquidTest to execute your tests. You should see summary results in your terminal, and detailed results should appear in the target/failsafe-reports/ directory in your Maven project tree.

Knowing your Enemy – Foundations of LiquidTest

Anthony Scotney — Thu, 25 Feb 2010 05:48:04 +0000

There is a great article by 37signals called “Have an Enemy”. By knowing your “enemy”, you know what you don’t want to be. This is pretty much how LiquidTest was conceived. We knew there were problems in the Test Automation space and we knew there were a lot of questionable practices by some of the established players in the space. The following is a list of principles LiquidTest was founded upon:

Built for Developers by Developers: From day one we focused on languages being used to write commercial grade products such as Java and C#, and on IDE integrations (Eclipse and Visual Studio). We never wanted our product to suffer from the vendor training and lock-in traps seen with the larger vendors that utilize proprietary languages. We also did not want to have a product developed for non-technical QA pitched at Developers.

Record and Replay without the black eye: We are finding that Record and Replay has taken a beating over the years, thanks to some of the products produced by the “Senior Citizens” in this space. Developers are rightly skeptical about how robust Record and Replay is but the simple fact is that when you get it right, it works! We have LiquidTest pretty close to “right” (three years of work by two distinct teams) and it records and replays GWT, ExtJS, Dojo, IceFaces, ZK, Backbase, etc.

Browsers, browsers, browsers: We wanted to use our skills with browsers (read WebRenderer) and build upon them. WebRenderer, our browser SDK that embeds Internet Explorer and Firefox, is the foundation of LiquidTest. Using real browsers gives real tests, which produce real results as the user would see them.

Easy to Integrate: Integrations are a key component of LiquidTest. The power of using real languages with real unit test frameworks is that they integrate into all the great Developer tools!

Controlling Cost: We do not want to make LiquidTest prohibitively expensive. One of the key gripes in this space is price. We totally agree! To say I was shocked when I saw the prices of the established products is an understatement. Given the vast majority of commercial tools in this space do not support recording against the vast majority of Web 2.0 frameworks/applications, it is amazing these guys even exist in this day and age.

Develop with Passion: We are passionate about getting LiquidTest perfect for our users. The whole LiquidTest team at JadeLiquid is extremely dedicated to improving the product. LiquidTest has been out in the wild for 12 months and we have already released 17 updates! We want to make the best possible tool, and the key to this is listening to users (Developers) and responding to their feedback. Passion is what drives us and the challenge is certainly set with automated testing in a Web 2.0 world.

Eclipse and LiquidTest UI Introduction

mbayazit — Tue, 10 Nov 2009 22:37:25 +0000

LiquidTest is available as a plug-in for the two most popular Integrated Development Environments (IDE), Eclipse and Visual Studio. This discussion (also available as a PDF here..) will focus on the Eclipse version and will provide Eclipse-specific tips for LiquidTest users.

Testers and/or Developers will benefit from some of the features that are available in the IDE (Eclipse) itself, that are not part of the LiquidTest plug-in. Additionally, this discussion will cover some features and functions that are available in the Eclipse UI due to the LiquidTest plug-in.

Eclipse-Specific Features:

Eclipse Package Explorer tab

Eclipse uses the Package Explorer tab to organize projects, JRE system library files, the LiquidTest plug-in jar files, the JUnit files and the source folder and the Eclipse packages that hold the LiquidTest scripts.

Eclipse Project creation

A user may want to create a new Eclipse project to hold LiquidTest scripts. To do this, select the Eclipse Package Explorer tab and either select File->New->Project or right-click in the Eclipse Package Explorer tab and select New->Project. For a project that will store Java/JUnit/Groovy (LiquidTest Script) test scripts, select Java->”Java Project”. For a project that will store .NET test scripts, select .NET->”.NET Project”. Provide a unique project name and click Finish.

Eclipse Package creation

Within an Eclipse project, you can further refine the location that LiquidTest uses to store scripts. It is recommended that you create a new package to store scripts. To do this, in the Eclipse Package Explorer tab, right-click the “src” folder in the Eclipse Project that you have just created and select New->Other. Next, select Package, provide a package name that is unique to this Eclipse Project and then click Finish.

Eclipse Perspective button

Eclipse Perspectives are used to customize the actions and views that are available to the user. Various tabs, buttons, windows and areas are visible when a particular Perspective is selected via the “Perspective” button in the upper right-hand corner of the Eclipse UI.

JUnit tab

The JUnit tab is used to track the status of a currently running LiquidTest test case, including iterations, errors and failures.

Failure Trace area

The Failure Trace area allows you to view the details of any failures that were detected in the test case run.

Break-points (for Java JUnit Test Scripts only)

Most LiquidTest users will not need to use break-points but if you need to (for example to pause the test execution to validate something), create your test script as usual, then in the LiquidTest Test code/script tab for the test of interest, select the line you want to set a breakpoint on, then in the area near the left-hand border of the test script tab, right-click and select “Toggle Breakpoint”.

To run the test case and use the breakpoint, you must use “Debug As” by right-clicking on the script and selecting “Debug As” and then selecting the appropriate test type (in this case, JUnit). When the playback gets to the breakpoint, execution will pause. To continue, use the Run->Resume menu item (or F8).

Refactoring (for Java JUnit Test Scripts only)

It is common for software projects to be refactored frequently to reorganize their form, without changing the external functionality. This involves activities such as renaming files, classes, methods, variables, etc. If this had to be done manually, it would be very difficult to know all of the places where this update must be made. Fortunately, Eclipse has a facility to do this automatically. This can be done in more than one way. In the Eclipse Package Explorer tab, you can rename a test script file (or other types as well) by right-clicking on that file and selecting Refactor->Rename. There are also other types of refactoring that are available on this menu as well. If you want to rename a class, method, variable, etc in a test script, simply select the item you want to rename, then right-click on it and select Refactor->Rename.

How to manage the areas of the Eclipse UI

The Eclipse UI is fairly flexible in how it presents information to the user.

Maximizing /Minimizing/Restoring areas

Individual areas can be maximized by clicking the Maximize button in the upper right-hand corner of the area.

Areas can be minimized by clicking the Minimize button in the upper right-hand corner of the area.

Areas can be restored by clicking on the Restore button for that area (which will be located to the far left and/or right sides of the screen).

Reset Perspective

As the user works with LiquidTest, they can make changes to the Eclipse Perspective as desired to customize the way information is displayed. To restore the default settings for a Perspective, make sure the Perspective is active (by using the Eclipse Perspective button) and then select Window->“Reset Perspective”.

Console tab

The Console tab provides detailed information about warnings, errors and any other unexpected events that are experienced when the test is being recorded or replayed.

Problems tab

This tab is only available in the Java perspective and provides detailed warnings about the test script code, such as code errors; methods, identifiers and asserts that are never used; type warnings, imported objects not used; etc. For this example, I have manually edited the test script to insert intentional errors.

LiquidTest Plug-In Features:

LiquidTest Perspective

LiquidTest takes advantage of Eclipse perspectives to customize the actions and views that are available to the user. Various LiquidTest-specific tabs, buttons, windows and areas are visible when the LiquidTest Perspective is selected via the “Eclipse Perspective” button in the upper right-hand corner of the Eclipse UI. You can verify that Eclipse is in the LiquidTest perspective by checking that LiquidTest is displayed in the upper right-hand corner.

Like other Eclipse Perspectives, if the LiquidTest Perspective has been modified, the user can restore the LiquidTest Perspective to its default configuration by first selecting the LiquidTest Perspective, then selecting Window->”Reset Perspective”. For more information on Eclipse perspectives, see: http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html

LiquidTest button

The LiquidTest button is located directly below the Eclipse menus (File, Edit, Source, etc.) and allows the user to create a new LiquidTest test script, Start Recording, Set LiquidTest Preferences and access online LiquidTest documentation.

LiquidTest Browser window

This is the window the LiquidTest user interacts with to create test scripts and observe the replay of these scripts.

”Finish Recording”

This button is used to finish a recording session.

“Lockdown and Inspect”/ “Unlock and Continue”

This button is used to allow several test creation actions to be accomplished, such as setting up data-driven form fields, using the LiquidTest Inspector and creating assertions to validate content. While the user is recording a test script, click “Lockdown and Inspect”. Then use the Inspector, data-driven and input field and/or create an assertion, then click “Unlock and Continue”.

Dynamic Element

Allows a user to specify that this object’s identification will change on different iterations of the test, so simply identify and locate the object by the full XPath.

Code Options

Pick which Code Option to use from a list of established Code Options. Code options allow the user to define how HTML objects are identified and are particularly useful for new web frameworks. For more information on code options, see: http://www.jadeliquid.com/liquidtest/docs/doku.php?id=general:recording_options

LiquidTest Actions

Allows the user to attach an Excel spreadsheet for parameterization data and to insert or run methods from other files.

LiquidTest Inspector tab

This tab is used when recording scripts, using the “Lockdown and Inspect” feature and for selecting the desired object to create an assertion to validate that content is appearing correctly or to parameterize data. To use this feature, start recording a script, navigate to the point where you want to use the Inspector and click “Lockdown and Inspect” and then click on the object of interest.

Structured tab

The Structured tab shows a lot of useful information about the HTML elements that appear on the page.

*XPath
The XPath LiquidTest utilizes to identify the HTML element.

*DOM tree
An orderly display of the HTML elements, including some information such as the name, id and value of the element.

*Properties of Selected Node
This area allows you to observe and select all the available properties of the selected element and also allows you to assert on any selected property.

*Asserts added to current page
Shows a listing of all the assertions that have been created for this page.

HTML tab

Shows the HTML code that has been downloaded to the browser.

LiquidTest Test code/script tabs

LiquidTest uses one area to group one or more LiquidTest Test cases which are selectable by clicking their individual tabs. Within these tabs, the user can observe the code, modify and save changes, run the test and more.

LiquidTest Event Viewer tab

This tab is located near the bottom of the Eclipse UI and allows the user to see what HTML events have occurred at any point during the recording process. This is useful to ensure that an activity has been completed before the test case recording engine proceeds to the next step.

LiquidTest Data Driven Fields tab

This tab is located near the bottom of the Eclipse UI and allows the user to see the properties of all the data-driven parameterization of fields, as well as the data-driven asserts that have been created for this test script.

The following information is displayed:

Type – Either “Bound Field” or “Assertion”;
Column Header – Which column is being used in the spreadsheet for this item;
XPath Bound – What XPath or identifier is being used to identify the element being data-driven;
Page Title – What is the title of the HTML page;
URL –The URL of the HTML page.

LiquidTest Assertion History tab

While the LiquidTest script is being recorded, this tab shows which assertions have been created and information about:

Assertion Type – What type of assertion is being performed (text content, attribute, etc.);
Verifying Value – The value that is being asserted;
Verifying XPath – The XPath or other identifier being used to identify the object;
Page Title – Title of the HTML page.
Page URL – Full URL of the page being tested.

LiquidTest Script Runner tab

This tab only appears when you are running a LiquidTest Script (Groovy) test case and provides technical information about a LiquidTest Script as it is being run, such as warnings, diagnostic messages, pass/fail etc. This is useful for script debugging.

LiquidTest Script Creation

To create a new LiquidTest test case – In the Eclipse Package Explorer tab, open the project that you want to store the test script in, then right-click the specific package you want to store this test script in and select New->”LiquidTest Test”. Change the Test Case Writer selection if needed, provide a name for the test case, add a data-driven spreadsheet if desired, click “Start Recording Now” and then click Finish.

Right-Click on Test Script menu-options (Run, Record, etc.)

Some actions can be invoked easily by right-clicking on the test script of interest and selecting:

“Run As”->”JUnit Test” (or “Ruby Application” or “TestNG Test”). This runs the test case;
“Record a Test Method” to start recording a new test method;
“Record Test Method After Selected Test Method” to replay the script to this point and start recording a new test method;
“Additional LiquidTest Recording Actions”->”Record Test Method from Current Page” to just start recording on the page that is currently loaded into the LiquidTest Browser tab;
“Additional LiquidTest Recording Actions”->”Record Test Method After Selected Methods from Files” to replay a test method from a different file and then start recording;
“Additional LiquidTest Recording Actions”->”Record Test in Current Method” to replay the test method back and then start recording in the same test method.

LiquidTest Preferences

This can be accessed via the LiquidTest button drop-down menu or the Eclipse menus via Window->Preferences->LiquidTest. Some basic preferences can be set at this level (such as default browser, cookie handling, mouse event handling, timeouts/delays and showing running tests).

More preferences can be set by selecting the LiquidTest sub-preferences:

Inspector – Set the border color, width and style for highlighting objects in the Inspector.

License – View license details and update the license key.

Recording – Set default test case type, code options, event tracking, default URL and lockdown options.

Screen Capture – Set preferences for where to store screen captures when test cases fail.

URL Configuration – Set URL replacement preferences to allow you to create scripts on one website and then play them back against another (for example, scripting against a test environment and running them against a production environment).

This document is available in PDF format from here..

Testing Dynamic Elements – Having a Plan B

dthomas — Tue, 13 Oct 2009 04:49:52 +0000

LiquidTest has many varied features and functions. In this blog post I will explain a small but important feature with an example. This feature is a small check box you see at the bottom of your browser when recording a test with LiquidTest, called Dynamic Element.

In this test, I am going to go to Ebay.com.au and I am going to search for a golf driver. After navigating to the site and entering into the search field “golf driver”, eBay does its magic and comes back with a list of results.

However, I want to test an eBay feature and that is the ability to sort the search results and in particular I want to test against the option “Distance: nearest first” (see below).

When you select this option, eBay will load up an internal frame requesting your postal code:

We enter our postal code (in our case, 7000) and then click the “Save” button. eBay then presents our search results in order (closest to furthest). Next, we press the LiquidTest “Finish record” button and LiquidTest writes the following test script:

Although LiquidTest produced a nice and simple to follow test script, there is a problem when I replay the test:

This failure is due to a dynamic element created by the “Distance : nearest to me” option. The elements ID is randomly generated, in this case we can see elements ID in the test script as “v4-1254714420097”. Some frameworks use Dynamic elements as a matter of necessity. With some tools, this can present a headache and a lot of extra work to code the test to allow for this.

However with LiquidTest, we have addressed this issue with a simple to use feature. Take the above test, this time when I am recording the test and I get to the internal pop up screen with the dynamic element. I will click on the LiquidTest “dynamic element” button before I input our postal code like so:

Selecting the Dynamic Element option in LiquidTest tells LiquidTest that the objects we are testing on this page have either dynamic content or IDs. When selected LiquidTest does not to use the object names or IDs but instead utilizes the full XPath for this element.

The newly recorded test will then be created like this:

The resulting test case uses a full XPath to reference the dynamic element. Because this does not reference specific ID’s or text content, this test will replay without issue.

Whilst we generally prefer to use the IDs for elements on a page as it creates a more robust test, sometimes it is not possible. When it isn’t possible, it is good to have a backup plan. So that’s why we added the Dynamic Element button, consider it “Plan B”. And best of all, as in this case, you don’t have to use XPaths for every element, just the elements that are dynamic.

Setting up LiquidTest with Subversion and Hudson (Continuous Integration) part 2

Anthony Scotney — Wed, 09 Sep 2009 04:47:56 +0000

This post follows on from part 1 where we walked through the Ubuntu, Subversion and LiquidTest (Eclipse) setup. Assuming that your project is now in your subversion repository we walk through the Continuous Integration setup with the popular (and Open Source) Hudson CI server.

Contents of this blog

Setting up Hudson
Configure Hudson from the Hudson web interface
The liquidtest.properties file
The Build File (build.xml)

Setting up Hudson:

1) Create the necessary directory and download Hudson:
mkdir /home/hudson
cd /home/hudson
wget –no-check-certificate http://hudson.gotdns.com/latest/hudson.war

2) Start up Hudson (note Hudson has an internal server that runs on port 8080 by default):
java -jar hudson.war

3) Navigate your Browser to the IP where your server resides and specify port 8080. eg:

http://192.168.161.128:8080/

Configure Hudson from the Hudson web interface

Assuming that you successfully started Hudson and that you have not “firewalled” any ports, you should see the Hudson welcome screen when navigating to http://192.168.161.128:8080 (or your Servers IP address – remember in part 1 we setup VMWare and used NAT).

Setup ANT (the Java build tool)
1) Configure ANT in Hudson: “Manage Hudson” -> “Configure System” -> “Add Ant” (under the Ant heading), give Ant a “name” and point it to your ANT install directory (then Save – the button is at the bottom of page), which in this case (set in part 1) is: /home/apache-ant-1.7.1/

Building your Hudson “New Job”:
1) On the Hudson welcome screen, click on the “New Job” option (on the left-hand menu – see screenshot above).
2) Give your Job an appropriate name and select “Build free-style software project”
3) Click on the “LiquidTestAutomation” (or whatever you called your job) and then click the “Configure” option.

Here we are met with lots of configuration options. To keep things simple I will run through the basic sections and selections pertinent to this setup.

Source Code Management:
1) Select “Subversion”

2) Enter the URL to your subversion server (if you followed the setup above you will need to “enter credentials” aka username:password) eg: http://192.168.161.128/svn/LiquidTestProject/
3) Enter your username and password (when prompted) and Save the project and re-open the Configuration screen (click project, then “Configure”). Note: If you did not save the project you will need to re-enter the SVN location URL (step 2 above).

Build Triggers: “Poll SCM” and add “* * * * *” to poll subversion every minute for changes to your Tests

Add build step: Invoke Ant
Select your “Ant Version” that you configured above
In the “Targets” field, put “runtests” (for more information on “runtests” see below in the build.xml file), and click “Advanced..” and add build.xml as your “Build File”

Post-build Actions:
Check the “Publish JUnit test result report” and add “**/*.xml” to the field.

Save..

Now click on “LiquidTestAutomation” and then “Build Now”. Your project should build and fail..

The liquidtest.properties file

The LiquidTest Server Edition (liquidtest-nodeps-x.x.x.jar) requires a properties file to set the license key. This properties file is named “liquidtest.properties”. Without the liquidtest.properties file LiquidTest will not run. If you do not have a liquidtest.properties file, create one with notepad (or nano!) and add the following line:

licenseKey=

After entering the license key you should submit this file to subversion, in the root directory of your project (see Part 1 of this blog if you are in doubt).

The Build file (build.xml)

In this tutorial we are using ANT to provide direction to Hudson on what to compile, run and how to report the results. Given that we are using ANT we need to populate our build.xml (download from here..) file with the following and check the file into Subversion in the root project directory (In LiquidTest, click on the file, right-click and select “Team..” and then “Commit..”):