You are viewing a plain text version of this content. The canonical link for it is here.
Posted to watchdog-dev@jakarta.apache.org by Morgan Delagrange <md...@yahoo.com> on 2002/07/23 22:50:21 UTC
[Proposal] Latka conversion in detail
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.
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?
- 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Latka conversion in detail
Posted by Ryan Lubke <Ry...@Sun.COM>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>