|
TOOL Guide Table
of Contents Published: October
21, 2002 |
Tool Guide
|
TOOL Guide Table
of Contents Published: October
21, 2002 |
The Test Object Oriented Library (Tool) is a library of test objects that handle all the communication with HTTP, HTTPS, SOAP, .NET, XML-RPC and JDBC hosts. Tool is designed to be called from a high level language, such as the TestMaker script language. This guide covers the overall design of Tool and the objects available to build intelligent test agents.
Modern software test automation tools need to meet these criteria:
Tool is a free open-source design for a library of test objects. The Tool design enables developers to build and run intelligent test agents. The test agents drive Web applications and SOAP-based Web Services as an everyday user would. Multiple concurrent agents test an application for scalability and performance under near real production settings.
The design of Tool should be language and implementation independent. While we will try and use good Object Oriented design and architecture, it should not be assumed that someone would need to implement Tool in a language that explicitly supports OO structures. (e.g. a pure C implementation - using OO techniques in C should be possible.)
Tool is a library. This means that on its own, Tool will not accomplish anything. There is no user interface that would allow an end user to use Tool on its own. Tool is intended to be used in other projects that offer this UI to an end user. With that in mind, the audience for Tool is Software Developers - not end users.
Tool should offer software developers a flexible framework for building test suites to test Web systems. While we are targeting software developers with Tool, we ought to give them all of the help that we can with being able to create products that can be used by end users that are not developers.
(or namespace or modules depending on what language you use)
datasource:
These Objects are used get data for use with making requests or for other things that require access to data files, databases, etc.
protocolhandler:
This contains the Objects related to making requests via a specific protocol. This is the request portion of a transaction.
response:
This is the response portion of a transaction that is the information returned from a request made with a protocol handler.
util:
This is for generally useful utilities that do not directly relate to the core functionality, but could be used by them or in code that would use them. Examples: encoding, cryptographic function, properties handling
(Hopefully the pseudo-UML makes a little sense.)
datasource:
- DataSource - An interface that needs to be implemented by DataSource
implementations to allow access to the data.
- Csv - Access data in a Comma Separated Values flat file.
- Tsv - Access data in a Tab Separated Values flat file.
- Db - Access information that is stored in a Database. If needed
by the language, make Database specific implementations of the
Db to access a specific database type.
Datasource <-- Csv
Tsv
Db <-- PostgreDb (if necessary)
OracleDb
protocolhandler:
- Protocol - Interface to implement to create a new Protocol type.
- Header - An interface to setting Header values for a protocol. Protocol
specific implementations will need to be provided.
- Body - An interface to setting the Body of a Protocol request. Protocol
specific implementations will need to be provided.
- ProtocolHandler - A facade in front of all of the Protocols that allows an
easy way to instantiate new objects (factory methods) and call methods on a
Protocol regardless of which specific type it is.
- *Protocol - The specific implementations of the different Protocol handlers.
Protocol <-- HTTPProtocol
SOAPProtocol
?
<>-- Header <-- HTTPHeader
IMAPHeader
?
Body <-- POP3Body
SOAPBody
?
ProtocolHandler <>-- Protocol
response:
- Response - Interface to implement to define a response that will be returned
by a specific protocol.
- ResponseLink - An interface that defines the access to Response items that
can be chained together with the ResponseChain to define how to deal with a
Response object. This is how searching responses and things of that sort
will be implemented.
- ResponseLinkConfig - An Object that is created to hold values used to
initialize a ResponseLink.
- *Response - The implementations of Protocol specific response types.
- ResponseChain - A Chain of Responsibility pattern class that allows a
response to be passed among many ResponseLinks.
Response <-- HTTPResponse
SOAPResponse
?
ResponseLink <-- HTTPSearchLink
?
<>-- ResponseConfig
ResponseChain <>-- ResponseLink
util:
- Codec - Interface to encoding/decoding methods.
- Crypt - Interface to cryptographic routines.
- Lingo - Utility that creates pseudo-text to use as subjects or bodies of
messages, form posts, etc.
- Queue - For languages where there is no Queue class, this provides a Queue
implementation.
- PropertyFinder - A class that hides the details of loading property files
that contain strings and other configuration directives and handles
dynamically changing the values of these.
Codec <-- Base64Codec
URLCodec
HexCodec
Crypt <-- ?
PropertyFinder
Lingo
Queue
Tool is written in Java and comes with JavaDoc code documentation. JavaDoc is the standard way Java engineers annotate their code. The JavaDoc code documentation for Tool is also found on-line at: docs.pushtotest.com.
Feeling like you need some help? Try the support pages. For more information, latest builds, source code and support community, check PushToTest web site at http://www.pushtotest.com.
Please submit bugs with example code to dev@lists.pushtotest.com or by posting bug reports on the Bug Reports forum on the PushToTest web site. Bug reports with sample code are highly appreciated!
Please e-mail general comments about Tool to: info@lists.pushtotest.com
The above email address is not a subscription list. It is simply a one-way channel that you can use to send comments to the Load development team. Please note that while we try to respond to each message we receive, we may not be able to respond to every individual message.
Additional
documentation, product downloads and updates are at
www.PushToTest.com.
While the TestMaker software is distributed under
an open-source license, the documentation remains
(c) 2002 PushToTest. All rights
reserved.
