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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
