WebTest lets developers write XML-based test suites so quickly, it’s almost fun!
Virtually everyone uses a browser every time the computer is switched on — the browser has become an integral part of a user’s computing experience. Since users can begin using Web-based software with little or no training, it reduces the “distance” between the user and the developer. However, testing Web-based software to ensure it is bug-free is a real challenge. Tools that automate the testing process make the QA engineer’s life easier. It’s even better if the test automation tool is easy to learn, and produces high-quality test suites, quickly.
WebTest is an automated Web functional testing tool. It is an open source tool released under the Apache License, version 2.0. The project was founded in 2001, and currently involves four full-time committers. The tool is written in Java, is built using the Apache Ant build system, and is platform-independent.
In this article, we’ll take a quick look at how to download, install and start using this tool.
To begin with, here are the prerequisites:
- JDK 1.5.x and higher
- Ant version 1.7.0 or newer (optional)
- WebTest’s distribution should contain the necessary parts from Ant 1.7.0, ready to run
- An archive manager utility to unzip the archive
Install and configure
Download the WebTest package build.zip from its website and extract it in any directory of your choice. The directory in which you extract the package is referred to as WebTest home. In this directory, the subdirectory lib/ contains the Java libraries that comprise the WebTest runtime, and the bin/ subdirectory contains shell scripts for UNIX and Windows, which start WebTest on the respective OS.
On UNIX-like operating systems, add the bin/ directory of your WebTest home to your PATH environment variable. For example, assuming that WebTest home is /usr/local/webtest, add the following line to your .bashrc (user-specific Bash init file):
export PATH=${PATH}:/usr/local/webtest/bin
Create a new WebTest project
WebTest contains a utility script to create a new project, with some examples ready to run. Open a new shell and execute the following command. You will be prompted for the name of the new project; in the example below, we name it newBuddy. If you just hit Enter, the default name myWebTestProject will be used.
$ webtest.sh -f webtest.xml wt.createProject Buildfile: webtest.xml Will use java Buildfile: webtest.xml wt.init: wt.createProject: [input] Enter your WebTest project name: [myWebTestProject] newBuddy [mkdir] Created dir: /home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy [copy] Copying 12 files to /home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy [echo] [echo] Your WebTest project >newBuddy< has been successfully created with some demo [echo] tests to get started. [echo] You can now just go to >/home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy< and run ant. [echo] BUILD SUCCESSFUL Total time: 7 seconds
Run the demo tests
Your newly-created project contains some ready-to-run Web tests that you can use as templates. You can run them by moving to the project directory and executing the following command. If you are behind a proxy, edit the build.xml Ant file to configure the proxy connection.
$ webtest.sh
You should see some activity in the shell window, and after a few seconds you will see the following output:
wt.openResultFile: [echo] Opening result file /home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy/results/index.html with firefox wt.junitLikeReports: [xslt] Processing /home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy/results/WebTestOverview.xml to /home/bhuvan/projects/cubit/tests/functional/webtest/newBuddy/results/WebTestOverview.junit.xml [xslt] Loading stylesheet /home/bhuvan/projects/cubit/tests/functional/webtest/resources/WebTestOverview2JUnit.xsl wt.countWebtestResults: wt.full: BUILD FAILED /home/bhuvan/projects/cubit/tests/functional/webtest/webtest.xml:427: 4 of 6 webtests have failed (2 successful)! Total time: 48 seconds
An HTML report file like the one shown in Figure 1 should be displayed in your browser.
Note: The demo test suite deployed while you created the project includes six tests, out of which four are expected to fail, as reflected in the sample report above.
Sample WebTest Script
A sample WebTest script is displayed below. It is shipped as part of the demo test suite when we create a WebTest project, as elaborated in the previous section. For details, refer to newBuddy/tests/googleWebTest.xml.
<?xml version="1.0"?> <!DOCTYPE project SYSTEM "../dtd/Project.dtd"> <project default="test"> <target name="test"> <webtest name="check that WebTest is Google's top 'WebTest' result"> <invoke url="http://www.google.com/ncr" description="Go to Google (in English)"/> <verifyTitle text="Google" /> <setInputField name="q" value="WebTest" /> <clickButton label="I'm Feeling Lucky" /> <verifyTitle text="Canoo WebTest" /> </webtest> </target> </project>
As the script’s name implies, the above test is specific to Google. It accesses the Google search engine, verifies it has received the Google home page, types the word WebTest in the input field, and clicks the “I’m Feeling Lucky” button. The title in the response page should be Canoo WebTest. Though the XML tags used in the above test are somewhat self-explanatory, let’s explore each of them for the sake of clarity:
- project — Denotes a WebTest project
- target — Denotes a unique Ant target in WebTest. A test suite may have multiple targets
- webtest — Provides the ability to specify and execute functional tests for a Web-based application
- invoke — Executes a request to a particular URL
- verifyTitle — Verifies the text in the HTML title tag for the returned page against the specified text
- setInputField — Sets the value of the named HTML input field to the supplied value
- clickButton — ‘Clicks’ the specified button in the HTML form
A list of WebTest tags is available here.
Why WebTest?
Selenium is another very good tool for writing automated test suites for Web applications. Why choose WebTest over Selenium? I’m not going to cover every aspect of the differences in detail; for that refer to this excellent blog post comparing the two. Depending on your application and your exposure, I hope the results cited there will make it easier to choose the tool most relevant for your needs.
