Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 20318 invoked from network); 22 Apr 2002 15:49:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Apr 2002 15:49:38 -0000 Received: (qmail 21868 invoked by uid 97); 22 Apr 2002 15:48:56 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 21742 invoked by uid 97); 22 Apr 2002 15:48:55 -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 21647 invoked by uid 97); 22 Apr 2002 15:48:54 -0000 Date: 22 Apr 2002 15:48:34 -0000 Message-ID: <20020422154834.47845.qmail@icarus.apache.org> From: dion@apache.org To: jakarta-commons-cvs@apache.org Subject: cvs commit: jakarta-commons/latka/src/distribution/conf tests.ent suite.ent suite.dtd standardValidations.ent report.dtd custom-tests.ent 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/04/22 08:48:34 Added: latka/src/distribution/bin latka.sh latka.bat latka/src/docbook xml-reference.xml users-guide.xml status.xml RELEASE_NOTES.txt release-plan-1.0.xml proposal.xml index.xml developers-guide.xml latka/src/distribution/tests/watchdog WatchdogServletSuite.xml WatchdogJSPSuite.xml processWatchdogServlet.pl processWatchdogJSP.pl latka/src/distribution/tests/samples TestTaglibsWebsite.xml TestCommonsWebsite.xml latka/src/distribution/tests/latka-self-test TestLatka.xml latka/src/distribution/conf tests.ent suite.ent suite.dtd standardValidations.ent report.dtd custom-tests.ent Log: Moved from top level directories into src Revision Changes Path 1.1 jakarta-commons/latka/src/distribution/bin/latka.sh Index: latka.sh =================================================================== #! /bin/sh # pass in the path to the XML file for the Latka suite # optionally override the default host and default port # # Author: Morgan Delagrange # Author: dIon Gillard # # Version: $Id: latka.sh,v 1.9 2002/01/28 00:54:30 dion Exp $ # # Set the LATKA_HOME environment variable to your latka install directory if [ -z "$LATKA_HOME" ] ; then LATKA_HOME=.. fi # Set up classpath for latka - . + all jars in latka/lib + latka/lib LATKA_LIB=$LATKA_HOME/lib LATKA_LIBS=${LATKA_LIB}/*.jar LATKA_CP=. for lib in ${LATKA_LIBS} do # this condition will be false if there are no jar files in LATKA_LIB if [ "$lib" != "${LATKA_LIBS}" ] ; then LATKA_CP=$LATKA_CP:"$lib" fi done LATKA_CP=$LATKA_CP:$LATKA_LIB LATKA_VM_ARGS=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol # run latka java -classpath $LATKA_CP $LATKA_VM_ARGS org.apache.commons.latka.Latka $* 1.1 jakarta-commons/latka/src/distribution/bin/latka.bat Index: latka.bat =================================================================== @echo off rem pass in the path to the XML file for the Latka suite rem optionally override the default host and default port java -classpath .;..\lib\jaxp.jar;..\lib\sax2.jar;..\lib\crimson.jar;..\lib\log4j.jar;..\lib\commons-httpclient.jar;..\lib\jakarta-latka.jar;..\lib\jakarta-regexp.jar;..\lib\jdom.jar;..\lib\xalan2.jar;..\lib\jsse.jar;..\lib\jnet.jar;..\lib\jcert.jar;..\lib -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol org.apache.commons.latka.Latka %1 %2 %3 %4 %5 %6 %7 %8 %9 @echo on 1.1 jakarta-commons/latka/src/docbook/xml-reference.xml Index: xml-reference.xml =================================================================== Morgan Delagrange
mdelagra@yahoo.com
Latka XML Reference
Latka XML Reference
byteLength validates the length of an HTTP(S) response
DTD <!ELEMENT byteLength EMPTY> <!ATTLIST byteLength min CDATA "0" max CDATA #IMPLIED label CDATA #IMPLIED>
Attributes Name Type Default Description min NUMBER 0 Minimum number of bytes required for a valid response. Implied. Defaults to 0. max NUMBER none Maximum number of bytes required for a valid response. Optional. When absent, there is no upper limit on the number of bytes in a valid response. label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A byteLength validation passes if the HTTP(S) response is at least min bytes long, and (when specified) at most max bytes long.
cookie validates the presence of an HTTP(S) cookie in a response
DTD ]]>
Attributes Name Type Default Description name CDATA none, but required The name of the cookie to look for. Required. value CDATA none, optional The value that the cookie with the specified name should have (if any). label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A cookie validation passes if the HTTP(S) response contains a cookie with the specified name. If a value is provided, the cookie must also have the specified value.
credentials username/password credentials for Basic HTTP authentication.
DTD ]]>
Attributes Name Type Default Description userName CDATA none, required User name. Required. password CDATA none, required Password. Required.
Parents
Description Contains credentials for HTTP Basic Authentication.
maxRequestTime validates the response time for an HTTP(S) request
DTD ]]>
Attributes Name Type Default Description millis NUMBER 30000 Maximum amount of time, in milliseconds, in which a response must be returned to be considered a valid response. Implied. Defaults to 30000 milliseconds, or 30 seconds. label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A maxRequestTime validation passes if the HTTP(S) response is obtained in no more than millis milliseconds.
param indicates a request parameter as part of an HTTP(S) request to be executed
DTD <!ELEMENT request (, )>
Attributes None.
Parents
Description A parameter to be submitted as part of a .
paramName the name part of a name/value pair parameter
DTD <!ELEMENT paramName (#PCDATA)>
Attributes None.
Parents
Description The name part of to be submitted as part of a .
paramValue the value part of a name/value pair parameter
DTD <!ELEMENT paramValue (#PCDATA)>
Attributes None.
Parents
Description The value part of to be submitted as part of a .
regexp validates the presence or absence of a regular expression within an HTTP(S) response
DTD ]]>
Attributes Name Type Default Description pattern CDATA none, but required. The regular expression to look for. cond Enumeration: true false true When true, the given pattern must match within the response. When false, the given pattern must not match within the response. ignoreCase Enumeration: true false false When true, case is ignored within the given pattern. label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A maxRequestTime validation passes if the HTTP(S) response is obtained in no more than millis milliseconds.
request indicates an HTTP(S) request to be executed
DTD <!ELEMENT request (?, *, ?)> <!ATTLIST request path CDATA #REQUIRED method (post | get) "get" host CDATA #IMPLIED port CDATA #IMPLIED label CDATA #IMPLIED>
Attributes Name Type Default Description path CDATA none, but required Request path. Required. method enumeration: get post get HTTP method. Implied. Defaults to get. host CDATA none Host to submit request to. Optional. When absent, uses default from . port NUMBER depends upon protocol Port to submit request to. Optional. When absent, uses default from . label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description An HTTP(S) request to be executed.
session wrapper for a sequence of s associated with the same state (session)
DTD <!ELEMENT session (+)> <!ATTLIST session sessionId CDATA #IMPLIED label CDATA #IMPLIED>
Attributes Name Type Default Description sessionId CDATA none Unique identifier for this session. Sessions with the same sessionId will share the same underlying state (e.g., cookies, etc.) label CDATA none Label associated with this session, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A session is a collection of s that share the same underlying state. For example, a cookie that returned in the response to one will be included in subsequent s.
statusCode validates an HTTP response code
DTD ]]>
Attributes Name Type Default Description code NUMBER 200 Numeric HTTP response code to expect. Implied. Defaults to 200. label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A statusCode validation passes if the HTTP(S) response code for the given request matches the value specified by code.
suite root element for a suite of tests
DTD <!ELEMENT suite ( ( | )+ )> <!ATTLIST suite defaultHost CDATA #IMPLIED defaultPort CDATA #IMPLIED label CDATA #IMPLIED>
Attributes Name Type Default Description defaultHost CDATA none Default hostname for s. Optional. defaultPort NUMBER none Default port for s. Optional. label CDATA none Label associated with this suite, which may be used in programatically generated documentation or reports. Optional.
Parents None.
Description A suite is a collection of s and s to execute.
validate indicates the suite of validations to apply to the current (and its response)
DTD <!ELEMENT validate ( | | | | | )+>
Attributes None.
Parents
Description Contains the set of validations to apply to the current (and its response).
xpath xpath - assuming the HTTP(s) response contains XML, checks if an XPath expression matches
DTD <!ELEMENT xpath EMPTY> <!ATTLIST xpath select CDATA #REQUIRED cond (true | false) "true" value CDATA #IMPLIED label CDATA #IMPLIED>
Attributes Name Type Default Description select CDATA none An XPath expression, designed to match a node in the XML body of the response. cond Enumeration: true false true When true, the given XPath expression must match within the response. When false, the given XPath expression must not match within the response. value CDATA none, optional The value that the matched node should have, if any. label CDATA none Label associated with this validation, which may be used in programatically generated documentation or reports. Optional.
Parents
Description A xpath validation passes if the HTTP(S) response body contains XML, and the specified XPath expression matches (or not, depending on cond)
1.1 jakarta-commons/latka/src/docbook/users-guide.xml Index: users-guide.xml =================================================================== Latka User's Guide
What is <firstterm>Latka</firstterm> Latka is a functional (end-to-end) testing tool. It is implemented in Java, and uses an XML syntax to define a series of HTTP (or HTTPS) requests and a set of validations used to verify that the request was processed correctly. Although Latka currently supports only HTTP and HTTPS request/response validations, it may be expanded to perform other sorts of functional testing as warranted. A simple example of a Latka XML test suite is shown in our sample Latka test suite. When processed, this example would verify that the Jakarta Commons homepage is present and that all the Commons Components have online documenation.
Running Latka A Latka test suite can be run: From a command prompt From the Latka web application From a JUnit TestRunner To run Latka as an ant task, we suggest you use the JUnit support of ant and write a small test case to invoke Latka, as discussed later
Running Latka from the command prompt There are two scripts (or batch files) shipped with latka: latka.bat - for Windows machines latka.sh - for Unix machines Both of the scripts take the following parameters: a test suite URL, e.g. file:./TestCommonsWebsite.xml or http://jakarta.apache.org/commons/latka/TestCommonsWebsite.xml Optionally properties files of Latka options can be specified using the propfile parameter: propfile:<file name> Optionally individual Latka options may be specified using the prop parameter: prop:<prop name>=<prop value> For more information about what properties you can pass to Latka, please see the Latka Properties definition
Running Latka from a web application (Under Construction) The Latka release distribution comes with a web application (latka-webapp.war) ready to deploy on a conforming Servlet 2.2/ JSP 1.1 container. For example, to install the Latka web application into a Tomcat 4 server, simply copy the .war file to Tomcat's webapp directory, e.g. [Win32] copy latka-webapp.war c:\tomcat4\webapps or [Unix] cp latka-webapp.war /usr/java/jtomcat4/webapps and restart Tomcat
Using the Latka Web App Once you've gotten the Latka web app running, it's straightforward to use. You can either Run a latka
Running Latka as a JUnit Test Case Here's hoping you're familiar with JUnit Latka ships with a class JUnitTestAdapter that bridges Latka and JUnit. You can use this class to create JUnit Tests from Latka's XML documents. For example, calling JUnitTestAdapter.createTestFromFile(fileName) with a valid Latka XML document's file name will return you back a JUnit Test, ready to be added to a TestCase. So, essentially you code a JUnit TestCase, and in the suite method, you add the Tests created by JUnitTestAdapter to the JUnit TestSuite. public static Test suite() { TestSuite suite = new TestSuite(); String fileName = "tests/samples/TestCommonsWebsite.xml"; suite.addTest(JUnitTestAdapter.createTestFromFile(fileName)); return suite; } Once you have Latka's suite as a JUnit TestSuite, you can run it using any JUnit TestRunner to execute the suite, including those shipped with ant.
Anatomy of a test suite (Under Construction) For a reference of the XML tags that can possibly be used in developing latka test suites, see The XML Reference A Latka test suite is an XML document with a top level element of suite
Latka Properties (Under Construction) Definitive list of properties and their meanings...
1.1 jakarta-commons/latka/src/docbook/status.xml Index: status.xml =================================================================== MorganDelagrange
mdelagra@yahoo.com
 DougSale
dsale@us.britannica.com
 RodneyWaldhoff
rwaldhof@us.britannica.com
 dIonGillard
trongus@yahoo.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) 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 1 Planned Next Release: 1.0, timeframe: 12 April, 2002
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) dIon Gillard
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: 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. 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
1.1 jakarta-commons/latka/src/docbook/RELEASE_NOTES.txt Index: RELEASE_NOTES.txt =================================================================== LATKA RELEASE NOTES ------------------- Note: Alpha and beta releases are not frozen in terms of the API. There may be changes before the final release. 1.0 Alpha 2 ----------- Webapp interface - Added last modified dates to the list of tests on the server - Added more HTML-friendly stylesheet for test results - Added servlet to view the XML of a Latka suite. This servlet resolves all external entities. Webapp and command-line interface - Added ability to set default properties from the classpath using the latka.properties file, and added default prop files to the command-line and webapp distributions - Removed unnecessary redundancy from labels for request failures and errors. - Removed labels from skipped requests, which were unnecessary and not permitted by the DTD. 1.0 Alpha 1 ----------- - First Latka release 1.1 jakarta-commons/latka/src/docbook/release-plan-1.0.xml Index: release-plan-1.0.xml =================================================================== dIonGillard
dion@apache.org
 Release Plan for Latka 1.0
Administrivia This document describes a plan for a 1.0 release of the Jakarta-Commons Latka component (for the remainder of this document, simply "Latka"). As per the Jakarta/ASF guidelines, this document doesn't mean anything until accepted by the relevant committer community via a lazy majority vote (hereafter, simply "lazy majority"). Once accepted, it may be replaced by an alternative plan, again subject to lazy majority approval. Non-binding votes (votes cast by those outside the relevant committer community) are welcome, but only binding votes are significant for decision making purposes.
Objective The objective of the 1.0 release of Latka is to provide a stable and robust release focused on design clarity, forward compatibility, and ease of use (i.e., with the intention of providing a stable foundation for the further evolution of the Latka component). Specifically, the 1.0 release seeks to introduce and evaluate changes based upon the following (ordered) criteria: Freedom from defects (deviation from the documented or reasonably expected behavior) Interface and design consistency and clarity, ease-of-use, and ease-of-extension. Forward compatibility. That is, the ability to add support for features that can be reasonably predicted without "breaking" the external (and to a lesser degree, internal) interface of the component The 1.0 release should also include: Adequate documentation (including both API-level/JavaDoc documentation as well documentation suitable for use on the Jakarta-Commons site) A substantial unit and functional test suite suitable for ensuring the quality and compatibility of release 1.0 and subsequent releases. A clear demarcation of the "internal" and "external" interfaces within Latka, as defined in the Versioning Guidelines document
Release Manager dIon Gillard (assuming no one else is really itching to do it)
Timeline (All days ending at 23:59:59 GMT in case of dispute.) Review Period Friday, March 29 - Friday, 5 April 2002 During the Review Period specific design, functional and contract changes to Latka will be considered on the Jakarta-Commons mailing list, using the following process: Any developer or committer that would like to see a specific change (or group of changes) enacted or rolled back will suggest it on the Jakarta-Commons mailing list Any interested committer that opposes a given change (or group of changes) is obligated to indicate this disapproval on the list during the Review Period. We will seek, but not strictly require consensus on each decision point. If consensus cannot be reached, any committer may call for a vote to resolve the issue via a lazy majority vote. The Review Period may be closed before 5 April 2002, given one "workday"'s notice and lazy majority approval. The Review Period may be extended by one week (at a time) given lazy majority approval, in case issues still need to be resolved. Implementation Period Friday, 5 April 2002 - Friday, 12 April 2002 (assuming the Review Period is not extended) During this period, any remaining implementation, testing and documentation will be completed. No new features or "public" interface changes will be considered in-scope at this time (short of a lazy-majority approved revised release plan or any "showstopper" defects). At the end of the Implementation Period, a formal release vote will be called, subject to lazy approval. A formal release vote may be called before 12 April, but after the end of the Review Period, if appropriate.
1.1 jakarta-commons/latka/src/docbook/proposal.xml Index: proposal.xml =================================================================== MorganDelagrange
mdelagra@yahoo.com
 DougSale
dsale@us.britannica.com
 RodneyWaldhoff
rwaldhof@us.britannica.com
 Proposal for Latka Package
(0) Rationale 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. 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.
(1) Scope of the Package The Latka project shall develop an XML-based syntax for HTTP-based functional tests. Latka will support, at the least, SSL communication and cookies. Included within Latka are classes that simulate a user agent. While the backend HTTP communication is handled by the HttpClient Commons component, the Latka interfaces simulate some of the behaviour of an actual web browser, including automatically passing cookies from request to request in a session. We hope to integrate these classes into a "useragent" package in HttpClient at some point, since they are a useful abstraction and not tied to Latka in any way, nor do they modify the core HttpClient classes. Latka also includes several validations that can be performed on the HTTP responses, including checking the status code, byte length, or request timing. In addition you will be able to customize Latka with your own validators by writing a couple of simple classes.
(1.5) Interaction With Other Packages 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 Logging component from Commons (not yet implemented) 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
(2) Initial Source of the Package The initial source has been committed to the Sandbox, and includes almost all of the functionality described above.
(3) Required Jakarta-Commons Resources CVS Repository - New directory latka in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general jakarta-commons@jakarta.apache.org mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [Latka]. Bugzilla - New component "Latka" under the "Commons" product category, with appropriate version identifiers as needed. Jyve FAQ - New category "commons-latka" (when available).
(4) Initial Committers The initial committers on the Latka component shall be: Morgan Delagrange Doug Sale Rodney Waldhoff TBD
1.1 jakarta-commons/latka/src/docbook/index.xml Index: index.xml =================================================================== Morgan Delagrange
mdelagra@yahoo.com
Latka (Version 1.0 Alpha 2)
Other Documentation See the XML Reference, User's Guide and API Docs for more detailed information.
What is Latka? Latka is a functional (end-to-end) testing tool. It is implemented in Java, and uses an XML syntax to define a series of HTTP (or HTTPS) requests and a set of validations used to verify that the request was processed correctly. Although Latka currently supports only HTTP and HTTPS request/response validations, it may be expanded to perform other sorts of functional testing as warranted. A simple example of a Latka XML test suite is shown in our sample Latka test suite. When processed, this example would verify that the Jakarta Commons homepage is present and that all the Commons Components have online documenation.
Installing Latka
Requirements JDK 1.3 or better (for optional web application) Tomcat 4.0 B7 or better - does not work in Tomcat 3.2, untested in other containers (for optional SSL support) Sun JSSE library
General installation Download and uncompress the Latka distribution. If you wish to perform Latka test over SSL, you need to configure your JVM with the Sun JSSE library.
Optional web application installation Copy the "webapp/latka-webapp.war" file from the distribution to the "webapp" directory of Tomcat. If you have already configured log4j for Tomcat, you should remove log4j.jar from the /WEB-INF/lib directory of the Latka webapp.
Using Latka
Running the sample tests Command-line interface Open a command prompt inside the "bin" directory of the distribution. Run the Latka batch script on one of the sample XML test suites (e.g. "latka file:../tests/samples/TestCommonsWebsite.xml "). Web application Go to the index page of the Latka web application. Select "Run a test from the server" In the test directory dialog box, enter the directory: <latka distrubution directory>/tests/samples Click on one of the tests to execute it.
Creating your own tests (More to come...) Examine the Latka DTD in the conf directory for a list of all available elements. See the samples for typical syntax.
Running tests Command-line interface Open a command prompt inside the "bin" directory of the distribution. Run the Latka script with no arguments for information on usage. Web application Go to the index page of the Latka web application. Select "Run a test from the server" In the test directory dialog box, enter the directory where your tests are located. Click on one of the tests to execute it.
Creating your custom validations (More to come...)
1.1 jakarta-commons/latka/src/docbook/developers-guide.xml Index: developers-guide.xml =================================================================== Latka Developers's Guide
Introduction These are informal notes gathered as I've started working on Latka. Hopefully they will make sense to those coming after me, and possibly clarify the current state for the existing
Coding Style Latka has some unusual coding conventions, which we've hopefully captured using a tool, CheckStyle . Onto the conventions... The Sun coding conventions are followed in most places, except for the items that follow private and protected member variables begin with an underscore, _requestSucceeded private methods also begin with an underscore on rare occasions (mainly when there is some public method and protected/private method with an otherwise identical signature) Javadoc on classes and methods is not yet complete. Feel free to help out here :-)
General Practices Here are some of the development practices of the Latka team Before committing any changes, run a cvs diff to ensure unexpected changes are not being introduced Before committing java source code changes, do a clean build of the project to ensure all code still compiles. Run all testcases to ensure the code isn't broken. Run the checkstyle task to ensure code meets the project's current standards Before committing changes to the web pages: Ensure the original docbook is valid by validating the XML against the docbook DTD do a clean build of the webpages target in the main build file and view the resulting output
1.1 jakarta-commons/latka/src/distribution/tests/watchdog/WatchdogServletSuite.xml Index: WatchdogServletSuite.xml =================================================================== 1.1 jakarta-commons/latka/src/distribution/tests/watchdog/WatchdogJSPSuite.xml Index: WatchdogJSPSuite.xml =================================================================== 1.1 jakarta-commons/latka/src/distribution/tests/watchdog/processWatchdogServlet.pl Index: processWatchdogServlet.pl =================================================================== while () { $doc .= $_; } print qq'\n'; print qq'\n'; print qq''; # remove junk $doc =~ s###sg; $doc =~ s###sg; $doc =~ s###sg; $doc =~ s###sg; # fix me - create sessions for each test category $doc =~ s#testName=\".*?\"##sg; # this is never relevant - latka has other ways to handle this $doc =~ s#debug="0" host="\${host}" port ?="\${port}"##sg; # make every gtest into a request $doc =~ s##\n\n$4\n$2\n#sg; # for gtests with no description $doc =~ s##\n\n$2\n#sg; # for gtests with no description $doc =~ s##\n\n$2\n#sg; # for gtests with no description $doc =~ s##\n\n$2\n#sg; $doc =~ s#returncode="200"##sgi; $doc =~ s#returncode="HTTP/1.0 200 OK"##sgi; $doc =~ s#returncode="500"##sgi; $doc =~ s#goldenFile="(.*?)"##sg; $doc =~ s#responseMatch="(.*?)"##sg; $doc =~ s#expectHeaders="(.*?):(.*?)"##sg; $doc =~ s#\s*requestHeaders="(.*?):(.*?)"#\n#sg; # what does this test do? $doc =~ s#content="(.*?)"##sg; # for tests with no validations, assume 200 check $doc =~ s#\s*#\n\n#sg; $doc =~ s#\s*#\n\n#sg; # apply the label to the first test $doc =~ s#\s*(.*?)\s*?(<[^>]*?)/>#\n$2 label="$1"/>#sg; print $doc; print "\n"; #now someone beautify me and we're done 1.1 jakarta-commons/latka/src/distribution/tests/watchdog/processWatchdogJSP.pl Index: processWatchdogJSP.pl =================================================================== while () { $doc .= $_; } print qq'\n'; print qq'\n'; print qq''; # remove junk $doc =~ s###sg; $doc =~ s###sg; $doc =~ s###sg; $doc =~ s###sg; # fix me - create sessions for each test category $doc =~ s#testName=\".*?\"##sg; # this is never relevant - latka has other ways to handle this $doc =~ s#debug="0" host="\${host}" port ?="\${port}"##sg; # make every gtest into a request $doc =~ s##\n\n$4\n$2\n#sg; $doc =~ s#returncode="200"##sgi; $doc =~ s#returncode="HTTP/1.0 200 OK"##sgi; $doc =~ s#returncode="500"##sgi; $doc =~ s#goldenFile="(.*?)"##sg; $doc =~ s#responseMatch="(.*?)"##sg; # apply the label to the first test $doc =~ s#\s*(.*?)\s*?(<[^>]*?)/>#\n$2 label="$1"/>#sg; print $doc; print "\n"; #now someone beautify me and we're done 1.1 jakarta-commons/latka/src/distribution/tests/samples/TestTaglibsWebsite.xml Index: TestTaglibsWebsite.xml =================================================================== &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; 1.1 jakarta-commons/latka/src/distribution/tests/samples/TestCommonsWebsite.xml Index: TestCommonsWebsite.xml =================================================================== &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; &commonValidations; 1.1 jakarta-commons/latka/src/distribution/tests/latka-self-test/TestLatka.xml Index: TestLatka.xml =================================================================== cookieName foo cookieValue bar 1.1 jakarta-commons/latka/src/distribution/conf/tests.ent Index: tests.ent =================================================================== %custom-tests.ent; 1.1 jakarta-commons/latka/src/distribution/conf/suite.ent Index: suite.ent =================================================================== %standardValidations.ent; %tests.ent; 1.1 jakarta-commons/latka/src/distribution/conf/suite.dtd Index: suite.dtd =================================================================== %suite.ent; 1.1 jakarta-commons/latka/src/distribution/conf/standardValidations.ent Index: standardValidations.ent =================================================================== "> "> "> "> "> "> "> "> 1.1 jakarta-commons/latka/src/distribution/conf/report.dtd Index: report.dtd =================================================================== 1.1 jakarta-commons/latka/src/distribution/conf/custom-tests.ent Index: custom-tests.ent =================================================================== -- To unsubscribe, e-mail: For additional commands, e-mail: