Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25020 invoked from network); 23 Jan 2002 02:29:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Jan 2002 02:29:25 -0000 Received: (qmail 12296 invoked by uid 97); 23 Jan 2002 02:29:31 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 12286 invoked by uid 97); 23 Jan 2002 02:29:31 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 27074 invoked by uid 97); 23 Jan 2002 02:13:52 -0000 Date: 23 Jan 2002 02:13:42 -0000 Message-ID: <20020123021342.89432.qmail@icarus.apache.org> From: dion@apache.org To: jakarta-commons-cvs@apache.org Subject: cvs commit: jakarta-commons/latka/doc status.xml X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N dion 02/01/22 18:13:42 Added: latka/doc status.xml Log: Initial conversion from HTML to DocBook Revision Changes Path 1.1 jakarta-commons/latka/doc/status.xml Index: status.xml =================================================================== MorganDelagrange
mdelagra@yahoo.com
DougSale
dsale@us.britannica.com
RodneyWaldhoff
rwaldhof@us.britannica.com
Status File for Jakarta Commons "Latka" Application
INTRODUCTION 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.
2. DEPENDENCIES Latka relies on: Java Development Kit (Version 1.3 or later)stitem> 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
3. RELEASE INFO Current Release: 1.0 alpha 2, see link here Planned Next Release: 1.0, timeframe:
4. COMMITTERS 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)>
5. DEVELOPMENT STATUS 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.
Todo items: Fix the documentation system :) It's currently horrible; a single HTML file, created by some GUI editor. I would very much recommend the XML DTD + stylesheet in the Anteater project (see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aft/Anteater/doc/), whose styled output may be (temporarily) viewed here. Add a universal mechanism for negating validators. Currently regexp and xpath validators implement negation internally as a special cond attribute. This adds somewhat to the internal complexity. It would be better to have the framework handle negation by being able to wrap tests in a <not/> element. Make the inclusion of individual validators optional at build time. Write unit tests for each validator, with a mock object implementing the Response interface
-- To unsubscribe, e-mail: For additional commands, e-mail: