Testing websites is a pain. Many regression tests for a website can be verified automatically, speeding up the quality assurance process and allowing the engineers to focus on the more important issues. Additionally developers may want to monitor their development, QA and production environment, so that they can be sure that everything is running as they expect.
Latka is an HTTP functional testing suite for automated QA, acceptance and regression testing. Latka suites are XML documents, which can be written and/or modified without writing Java code. Latka tests can be created quickly and modified easily, even by engineers without Java experience.
Latka relies on:
Java Development Kit (Version 1.3 or later)
A JAXP 1.1 implementation
A SAX 2.0 parser conforming to the JAXP 1.1 APIs
An XSLT parser conforming to JAXP 1.1
HttpClient from Commons - for HTTP communcation
Jakarta Log4J logging package
JUnit - for testing
JSSE - SSL support (optional at runtime)
Jakarta-Regexp - regular expression tests and XML preprocessing (for variable support)
JDOM - for building XML reports
Current Release: 1.0 alpha 1
Planned Next Release: 1.0, timeframe: 12 April, 2002
The following individuals are the primary developers and maintainers of this component. Developers who plan to use Latka in their own projects are encouraged to collaborate on the future development of this component to ensure that it continues to meet a variety of needs.
Morgan Delagrange
Doug Sale
Rodney Waldhoff
Jeff Turner (part-time)
dIon Gillard
Latka development status:
Latka 1.0 Alpha 1 released
Latka library and command line interface:
Fully functional, but with potential interface changes forthcoming.
Latka tag library (in Jakarta Taglibs):
Experimental, unstable.
Latka web application (in Commons Sandbox):
Experimental, promising but unstable.
Add a universal mechanism for negating
validators. Currently regexp and xpath validators implement negation internally
as a special
Make the inclusion of individual validators optional at build time.
Set up Latka to use the proxy support of later HttpClient builds
Write unit tests for each validator, with a mock object implementing the Response interface
Fix the webpages build so that it builds into the build/docs directory and then copies to commons
Create better documentation, especially the User's Guide and Developer's Guide
Ensure coding standards are consistent across the project's codebase, preferably using a tool such as CheckStyle
Add XMLValidate tasks to the build file so that any XML doc with a DTD is checked before used