You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Serge Knystautas <se...@lokitech.com> on 2002/03/05 19:42:17 UTC
Latka notes
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.
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. 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.
3. Better ant/junit integration
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.
Comments?
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Latka notes
Posted by dIon Gillard <di...@multitask.com.au>.
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.
>
>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.
>
This doesn't sound like it fits in with what Latka already does; it
sounds like an external checking/generation process that's completely
outside of the functional testing. Don't get me wrong, I like the idea
of generating latka suites off other documents, but don't think it's
necessarily part of Latka.
>2. JTidy for HTML validation
>I would really like to be able to validate that the HTML in a site is well
>formed. 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 like a good custom validator, and a good fit with Latka.
>3. Better ant/junit integration
>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.
>
I use Latka with ant a lot. The user's guide (
http://jakarta.apache.org/commons/latka/users-guide.html ) talks about
creating JUnit suites from a Latka Suite and running that. So b) above
is just the usual JUnit task in ant. Is there something more you'd need?
>Comments?
>
>
>Serge Knystautas
>Loki Technologies - Unstoppable Websites
>http://www.lokitech.com/
>
--
dIon Gillard, Multitask Consulting
http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Latka notes
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 05, 2002 at 09:54:55PM -0500, Serge Knystautas wrote:
> I don't think I explained my idea 1 very well based on comments.
>
> The issue I'm facing is making sure my latka suite stays current with the
> site as developers maintain the site. For an initial import, I might have a
> webapp with 350 JSPs... I don't want to manually build the latka suite for
> that. More importantly, as the team of developers add more JSPs, I want to
> know that some schmuck didn't add a JSP to CVS and not add it to the
> functional test.
>
> I would start with just a file system dir list, recursing through subdirs
> and listing all *.jsp files. (no link checking or wget or anything
> complex... just pure dir.list() with recursion). This would create a list
> like:
> /test.jsp
> /index.jsp
> /login.jsp
> /contacts/list.jsp
> /contacts/add.jsp
> /contacts/edit.jsp
> It would take these URLs and build the latka suite file. If there already
> was a latka suite file, it would append the files not already in there.
> Really this is just a tool/script to maintain the latka suite file.
Perl, or shell would be easiest.
If you want to keep location-independence (list URLs, not file paths),
you could write a servlet that returns a list of directory contents as
XML. Then use Ant's <get> to retrieve the XML listing, <style> to
transform it into a Latka XML file, and off you go.
> I was getting somewhat ahead of myself with the "meta" decription, but I was
> thinking the filtering could get more advanced so that I included "*.jsp"
> and "*.html", but excluded everything in "/include" since those pages are
> not directly called. Maybe I should just fashion this as an ant task so I
> can leverage it's include/exclude file pattern capabilities.
Except in Ant you can't iterate over items in a fileset. Maybe there's
some 3rd party tasks for that.
> On an unrelated note, I thought of two other validators... a) link checking,
> and b) xml validation (if your servlet is supposed to output XML instead of
> HTML). Anyone else working on these kind of validators?
XML validation should be very easy (XPath does it for free). Link
checking might need the JTidy one's capabilities first. AFAIK, no-one is
working on them.
--Jeff
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Tuesday, March 05, 2002 5:34 PM
> Subject: Re: Latka notes
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Latka notes
Posted by Serge Knystautas <se...@lokitech.com>.
I don't think I explained my idea 1 very well based on comments.
The issue I'm facing is making sure my latka suite stays current with the
site as developers maintain the site. For an initial import, I might have a
webapp with 350 JSPs... I don't want to manually build the latka suite for
that. More importantly, as the team of developers add more JSPs, I want to
know that some schmuck didn't add a JSP to CVS and not add it to the
functional test.
I would start with just a file system dir list, recursing through subdirs
and listing all *.jsp files. (no link checking or wget or anything
complex... just pure dir.list() with recursion). This would create a list
like:
/test.jsp
/index.jsp
/login.jsp
/contacts/list.jsp
/contacts/add.jsp
/contacts/edit.jsp
It would take these URLs and build the latka suite file. If there already
was a latka suite file, it would append the files not already in there.
Really this is just a tool/script to maintain the latka suite file.
I was getting somewhat ahead of myself with the "meta" decription, but I was
thinking the filtering could get more advanced so that I included "*.jsp"
and "*.html", but excluded everything in "/include" since those pages are
not directly called. Maybe I should just fashion this as an ant task so I
can leverage it's include/exclude file pattern capabilities.
On an unrelated note, I thought of two other validators... a) link checking,
and b) xml validation (if your servlet is supposed to output XML instead of
HTML). Anyone else working on these kind of validators?
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 5:34 PM
Subject: Re: Latka notes
> 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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Latka notes
Posted by Jeff Turner <je...@socialchange.net.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Latka notes
Posted by Joaquin Salvachua <js...@dit.upm.es>.
On Tue, 5 Mar 2002, Serge Knystautas wrote:
Hello,
>
> 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.
>
> 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.
>
RDF may be perfect for this. Is an w3 consortium standard for metadata.
Was develop to model the p3p web annotation application but is growing
very fast.
(http://www.w3.org/RDF/)
The semantic web vision is developing over it:
perhaps i can develop a model for the tests (i made some formal testing of
ISO protocols some years ago).
regards
Joaquin
>
> Comments?
>
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
-----------------------------------------------------------
Joaquin Salvachua tel: +34 91 549 57 00 x.367
Associated Professor +34 91 549 57 62 x.367
dpt. Telematica
E.T.S.I. Telecomunicacion
Ciudad Universitaria S/N fax: +34 91 336 73 33
E-28040 MADRID SPAIN
mailto: jsalvachua@dit.upm.es // http://www.dit.upm.es/~jsr
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>