jakarta-watchdog-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Lubke <Ryan.Lu...@Sun.COM>
Subject Re: [Proposal] Latka conversion in detail
Date Wed, 24 Jul 2002 16:19:44 GMT
On Tue, 2002-07-23 at 16:50, Morgan Delagrange wrote:
> Hi all,
> 
> I made a first pass at converting the JSP tests to a
> format which, I think, is more organized:
> 
> http://cvs.apache.org/viewcvs/jakarta-watchdog-4.0/latka-scratch/src/distribution/tests/
> 
> The idea is that we use ENTITY declarations to specify
> each package in the Watchdog suite.  Then you can
> place any entities you want in a suite, which should
> allow you to construct tests as large as all the
> Servlet and JSP tests combined, or as small as a
> single package.
> 
> http://cvs.apache.org/viewcvs/jakarta-watchdog-4.0/latka-scratch/src/distribution/tests/dtds/jsp-tests.ent
> 
> http://cvs.apache.org/viewcvs/jakarta-watchdog-4.0/latka-scratch/src/distribution/tests/dtds/servlet-tests.ent
> 
> I think that there would be a physical XML
> file for running just the JSP tests, just the Servlet
> tests, or both at the same time.  It may also be
> possible to construct a command-line interface that
> will allow you to select a single entity or group of
> entities to execute, removing the need for XML files
> that exercise each package.  I think JDOM allows you
> to generate entities dynamically, but I'd need to
> experiment.
> 
> Part of this proposal involved changing the mappings
> (servlet, filter, etc.) in the servlet-tests and
> servlet-compat webapps to use fully qualified package
> names as test paths instead of the current, cryptic
> versions.  I made a programmatic pass at this, which
> you can find here (JDOM messed up the spacing a bit):
> 
> http://cvs.apache.org/viewcvs/jakarta-watchdog-4.0/latka-scratch/src/distribution/tests/servlet-tests.web.xml
> 
> These are working test suites.  The JSP tests seem to
> run perfectly.  The Servlet tests currently produce 21
> errors (and 327 successes :), most of which I
> introduced when I remapped the Servlets.  Most of the
> errors introduced are probably trivial; a few might
> require minor changes to the test servlets.  
> 
> I think this new servlet mapping format is much more
> clear.  As an example, here is a GTest element with
> the old servlet mapping and the corresponding Latka
> test with the proposed new servlet mapping:
> 
>   GTest:
>   <watchdog 
>     request="GET
> /servlet-tests/hsreqw/HttpServletRequestWrapperConstructorTest
> HTTP/1.0"
>    
> testName="HttpServletRequestWrapperConstructorTest"
> debug="0"
>     host="${host}" port="${port}" exactMatch="true"
>    
> goldenFile="${wgdir}/javax_servlet_http/HttpServletRequestWrapper/HttpServletRequestWrapperConstructorTest.html"
>     assertion="A HttpServletRequestWrapper object
> should be returned when the request object is passed
> into the constructor. Java Specification v2.3 Sec 14."
>     testStrategy="Construct a request object wrapping
> the given request."
>         />
> 
>   Latka:
>   <request followRedirects="false" version="1.0"
>       label="HttpServletRequestWrapperConstructorTest"
>      
> path="/servlet-tests/tests/javax_servlet_http/HttpServletRequestWrapper/HttpServletRequestWrapperConstructorTestServlet">
>     <validate>
>       <!--TEST STRATEGY: Construct a request object
> wrapping the given request.-->
>       <goldenFile
> fileName="${servlet-wgdir}/javax_servlet_http/HttpServletRequestWrapper/HttpServletRequestWrapperConstructorTest.html"
>           ignoreWhitespace="true" 
>           label="A HttpServletRequestWrapper object
> should be returned when the request object is passed
> into the constructor. Java Specification v2.3 Sec 14."
> />
>     </validate>
>   </request>
> 
> I think tying the servlet mapping to the test package
> will make maintenance and development tasks easier.
> 
> If we decide to proceed down this path, we would need
> to winnow away the remaining errors (shouldn't take
> long).  Then we'd want to write a Latka driver for
> Watchdog, which could plug the known directory
> structure and variables of the Watchdog tests into
> Latka automatically.  Then I believe we'd be close to
> something releasable.

+1.  I think this looks good.  Only item I would like to add is that
we rework the watchdog directory structure.  It's a bit unorganized as
it stands now (at least that's my opinion).


> 
> I haven't been spending any time on the non-4.0 tests,
> and I would just as soon leave them be, unless there
> were strong objections to the contrary.
> 
> Comments?

Another thought is the mavenization of Watchdog.  This seems the be the
current trend, and I could see some benefits for doing so.

Anyone against going this route?

> 
> - Morgan
> 
> 
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> --
> To unsubscribe, e-mail:   <mailto:watchdog-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:watchdog-dev-help@jakarta.apache.org>
> 



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


Mime
View raw message