LogiTest User's Guide

Testing of applications is crucial to providing user's with the best and most stable application possible. Unfortunately there are very few applications at this time for testing Internet-based applications. This is the gap that LogiTest fills.

Note: LogiTest uses Sun's browser component which is provided with Swing for rendering HTML documents. This browser only supports HTML 3.2 and there are many problems with its handling of HTML documents. If you know of any open source or free Java browser components, please drop me a line at me@anthonyeden.com.

Note: This documentation may be imcomplete. Features described within may or may not appear in the current version of this software.

• Features
• Getting Started
• Scripting
• Using Paths
• Creating Testlets
  • Implementing Your Testlet
  • Registering Your Testlet
• Acknowledgements
• Legal

LogiTest has the following features:

• Open source and free
• Easy-to-use user interface
• Tests are XML documents
• HTTP, HTTPS, and file protcols
• Cookies
• Browser history
• Multiple views of Internet resources (browser, formatted source code, DOM tree)
• Scriptable through Bean Scripting Framework

Please see the TODO.txt document.

There are two ways to run the LogiTest application:

1. If you are using Windows or X Windows (or some other *NIX GUI) you should be able to double click the LogiTest.jar application to execute LogiTest. You can also execute LogiTest with java -jar LogiTest.jar.
2. Navigate to the LogiTest/bin directory and execute the run.bat file for Windows, or the run.sh file for UNIX/Linux (Note: UNIX/Linux users will need to change the executable bit with chmod u+x run.sh.)

A new untitled test will automatically be created.

Note: As of version 0.6 all preferences will be stored in your home directory in a subfolder .logitest.

First you will need to add some resources to the test. To add a resource enter the desired URL in the browser and click "Go" (or press return.) Once the page is displayed, click the plus icon to append it to the Test's resource list.

You can also add a resource by right-clicking the Test name and selecting "Add...".

Enter the URL to the resource or click the "Browse..." button to select a local file. You can select a request method ("GET" and "POST" methods are supported) as well as specify a delay time in milliseconds. The delay time will be used to pause before the resource is loaded. You can use this to emulate pauses by users.

Resources can include name/value pairs which will be submitted as request headers or parameters during playback. To add a name/value pair right click the table and select "Add".

Once you have added a resource, you will need to add one or more testlets to that resource. Testlets provide test cases. LogiTest comes with two Testlets, but it is easy to add more.

To add a testlet, right-click on the resource you would like to add the testlet to and select the "Add..." option. A dialog will appear with the available testlets. Select the testlet and click "OK".

You must then specify the parameters for the testlet.

In the screenshot below the testlet is configured to locate the text "User's Guide" in the document path "html/head/title". You can enter any Perl 5 regular expression in the expect field and it will be evaluated at test time. The path field requires a path to the element or attribute within the document similar to XPaths (in fact the path syntax is a subset of the XPath specification.) For more information on paths, see the Using Paths section of this user's guide.

You can also specify that the testlet should check all of the children below the specified path to locate the text by checking the Recursive check box. (Note: attributes are not currently tested in recursive mode.)

You can add as many resources and tests as you would like. You can also set the name of the Test and add a description at any time by right-clicking on the Test.

You are now ready to execute your test. You may want to save your test now if you have not already done so by clicking on the "Save" icon or selecting the File->Save menu item.

To execute the current test, click the "Play" icon on the toolbar or select the Run->Play menu item.

Testlets which pass will be represented by a green "T", while testlets that fail will be represented by a red "T". Untested testlets are represented by a black "T". You can also disable tests by right-clicking on the Testlet and selecting the "Disable" option. The testlet will then be represented by a grey "T" until it is enabled again, at which time it will display the color of the last tested result.

Test results will also be printed in the lower split pane.

Resources and testlets can be cut and pasted from the test tree to be configured to playback in any order. The test tree also supports unlimited undo.

LogiTest can be controlled with scripting languages through IBM's Bean Scripting Framework (BSF). Any scripting language which supportes BSF can be used to control LogiTest.

To execute a script select the Run menu item from the Script menu. You will be prompted to load a script. The script that you load will be executed immediately if the scripting language is installed. Currently LogiTest supports scripting with JavaScript and Python.

The following objects and methods are available for scripting:

LogiTest supports locating elements in a document with XPath-like paths. The following path elements are supported:

More examples:

A few notes about paths:

• Path indexes, also known as predicates (i.e. [1]) start at 0. Thus, 0 refers to the first element in a document with the specified name.
• Attributes should only be applied to the last part of a path.

It is possible (and likely) that there will be times when the testlets provided with LogiTest will not provide the logic required to properly test your applications. The good news is that creating your own Testlet is easy.

Custom testlets must extend from the Testlet base class. The Testlet base class is defined as follows:

public abstract class Testlet implements Editable{

	public String getProperty(String name);
	
	public int getState();
	public void setState(int state);
	
	public boolean isEnabled();
	public void setEnabled(boolean enabled);
	
	public abstract boolean test(Resource resource) throws Exception;
	
	public void readConfiguration(Element element);
	public void writeConfiguration(Element element);
	
	public String toString();

}

Here are the descriptions of each method:

public String getProperty(String name)

Return a relavent property value. Standard properties are (as defined in the Testlet interface):

DISPLAY_NAME - A user readable display name for the Testlet.
DESCRIPTION - A short description of the Testlet.
AUTHOR - The Testlet author's name.
VERSION - The version of the Testlet.

public int getState()
public void setState(int state)

Accessors for the last state of the Testlet. Possible values are defined in the Test class (UNTESTED, PASSED, FAILED).

public boolean isEnabled()
public void setEnabled(boolean enabled)

Accessors for the enabled state of the Testlet. If this method returns true then the Testlet will not be executed at test time.

public boolean test(Resource resource) throws Exception

The actual test method. You must override this method and return true if the test passes or false if the test fails. This method can throw any Exception.

public void readConfiguration(Element element)
public void writeConfiguration(Element element)

Read and write the configuration for the testlet. The configuration will be stored with the Test (and in XML format). The default behavior of these methods is to do nothing. Testlet implementations which want to load and store configuration information should override these methods. The element argument is a JDOM Element. The name of this element is currently LogiTest:testlet, but this should not matter to the testlet as the testlet should only add sub elements.

For an example of a testlet which loads and saves information, see org.logitest.testlet.ExpectTestlet.

public String toString()

Return a String reprsentation of the testlet which is human readable. The AbstractTestlet provides an implementation of this method which returns the DISPLAY_NAME property value if it exists or the testlet class name if the DISPLAY_NAME property is not set.

Custom Testlets must also provide implementations for the methods in the Editable interface. These methods are provided for displaying user interfaces for editing testlets.

public interface Editable{

	public boolean save();
	public void revert();
	
	public Component getEditor();
	public String getEditorTitle();

}

Here are the descriptions of each method:

public boolean save()

Save the current editor's values to the testlet's internal fields. This method can return false to indicate that the save failed.

Note: this method should not persist the testlet to a storage system, it should merely update the internal fields. See the writeConfiguration() method for saving to a persistant storage system.

public void revert()

Revert the GUI to the internal data of the testlet.

Note: this method should not load testlet from a persistant storage system, it should merely update the GUI with the values from the internal fields. See the readConfiguration() method for loading from a persistant storage system.

public Component getEditor()

Get a GUI component suitable for editing the testlet. While a Component must be returned, testlet authors are encouraged to use Swing for their testlet's user interface.

public String getEditorTitle()

Return a String suitable for displaying in an editor window's title bar.

In order for the LogiTest application to recognize your Testlet, you must include it in the classpath and add an entry to the config.xml file (i.e. <LogiTest:testlet name="My Testlet" id="mypackage.MyTestlet"/>). The config.xml file is located in LogiTest.jar. You can open this file and extract the default config.xml file with any ZIP tool. Add your testlet to the configuration and save it back in the LogiTest.jar file.

Support for the following standards is either already included in LogiTest or is in the process of being added:

• RFC 2109 - HTTP State Management Mechanism

This product includes software developed by the JDOM Project (http://www.jdom.org/)

This product includes software developed by the Apache Software Foundation (http://www.apache.org/)

Thanks to the authors of JTidy (http://www.sourceforge.net/projects/jtidy).

Thanks to Oroinc and the developers of OROMatcher (http://www.savarese.org/oro/).

This software is available under an Apache-style open source license.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.