Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Wed, 6 Mar 2002 09:34:49 +1100
From: Jeff Turner <jeff@socialchange.net.au>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: Latka notes
Message-ID: <20020306093449.C16610@snow.socialchange.net.au>
References: <03cf01c1c475$7a08a850$650d07d8@STACCATO>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <03cf01c1c475$7a08a850$650d07d8@STACCATO>;
 from sergek@lokitech.com on Tue, Mar 05, 2002 at 01:42:17PM -0500

On Tue, Mar 05, 2002 at 01:42:17PM -0500, Serge Knystautas wrote:
> I was just talking with a coworker about how to build some automated tests
> for our webapp, and sure enough Latka does a lot of what I was thinking.  I
> had a few other todo items I might contribute, assuming I can get my client
> to pay or can otherwise find the time.  I thought I'd bring up the ideas
> first to get some feedback on whether this is going in a good or bad
> direction:
> 
> 1. meta process for test definition generation/maintenance
> I'd like to define a "meta" XML file for a webapp that could declare
> something like "all HTML pages and JSPs" in this webapp should be tested.
> Then new meta process code would use that meta XML to check that the Latka
> test definition meets these requirements... it would the recurse through the
> files in a webapp and look for them in the latka test file.

How would you go about determining the URLs of "all HTML pages and
JSPs"? Is this really *all* (ie you have inside information; it's your
webapp you're testing), or just visible from the usual application
workflow? Ie, is the list created by hand or created through a wget-like
follow-the-links strategy?

> If there were gaps, the meta check could either a) fail with a list of pages
> that aren't included or (my preference) b) add them to the test file with
> some comments (and stop before running the latka test).  By default it could
> just require 200 status codes for those newly spotted pages.  The tester
> could then look at the bottom of the latka test file, and cut and paste the
> definitions up to suites or to more understandable places in the file, and
> otherwise flesh out the validations.
> 
> 2. JTidy for HTML validation
> I would really like to be able to validate that the HTML in a site is well
> formed.

If you mean well formed in the XML sense (XHTML), you could use the
XPath validator, and just validate for something like '/'.

> I've tried doing it with a servlet filter, but using Latka would
> make much more sense.  Ideally we could define the JTidy settings for a site
> and whether to test all by default, and let individual requests override
> that.

Sounds good.

> 3. Better ant/junit integration

Wasn't there an Ant task for running Latka in the works? Dion?

> I'd have to see what's already there, but as I use ant to do my builds
> already, I'd like to have 2 custom taskdefs that will a) do the meta
> checking that the latka tests are complete and b) run the latka test.

If you're really keen on Ant integration, there's another testing
framework called Anteater (http://sourceforge.net/projects/aft), which
is 100% Ant tasks. It inherits a lot of expressive power from Ant
itself. Eg, you can pattern-match or XPath-match, and then store the
matched pattern/XML in an Ant property. You can also use Ant's
<parallel> to start/stop Tomcat servers.


--Jeff

> Comments?
> 
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>