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/17 18:35:58 UTC
GTest to Latka conversion near completion
Hi all,
Last month, Ryan propsed converting the current Watchdog tests from GTest to
Latka:
http://marc.theaimsgroup.com/?l=watchdog-dev&m=102489712116217&w=2
Ryan and I have made a lot of progress with the conversion effort. The
current versions of Latka, HttpClient and Watchdog now produce only 4 errors
(error report follows:
---------------
............................................................................
............................................................................
.......................................FF...................................
......................................................F...........F.........
............................................
http://localhost:8080/servlet-tests/GetHeader_01Test (GetHeader_01Test)
REQUEST FAILED (10 millis)
Returns null if the request does not have a header of that
name,specified in the Java Servlet Pages Specification v2.3, Sec 14:
EXPECTED TO MATCH GOLDEN FILE:
\lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
ServletRequest\GetHeader_01Test.html
FAIL*** : Live token = FAILED, did not match golden file token = PASSED
http://localhost:8080/servlet-tests/GetHeadersTest (GetHeadersTest)
REQUEST FAILED (10 millis)
Returns all the values of the specified request header as an Enumeration
of String objects.,specified in the Java Servlet Pages Specification v2.3,
Sec 14: EXPECTED TO MATCH GOLDEN FILE:
\lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
ServletRequest\GetHeadersTest.html
FAIL*** : Live token = FAILED<BR>, did not match golden file token = PASSED
http://localhost:8080/servlet-tests/hsreqw/HttpServletRequestWrapperGetHeade
rsTest (HttpServletRequestWrapperGetHeadersTest)
REQUEST FAILED (0 millis)
Test for default behavior of this method to return getHeaders(String
name) on the wrapped request object, specified in the Java Servlet Pages
Specification v2.3, Sec 14: EXPECTED TO MATCH GOLDEN FILE:
\lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
ServletRequestWrapper\HttpServletRequestWrapperGetHeadersTest.html
FAIL*** : Live token = FAILED, did not match golden file token = PASSED<BR>
http://localhost:8080/servlet-tests/hsreqw/HttpServletRequestWrapperGetReque
stURLTest (HttpServletRequestWrapperGetRequestURLTest)
REQUEST FAILED (0 millis)
Test for default behavior of this method to return getRequestURL() on
the wrapped request object, specified in the Java Servlet Pages
Specification v2.3, Sec 14: EXPECTED TO MATCH GOLDEN FILE:
\lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
ServletRequestWrapper\HttpServletRequestWrapperGetRequestURLTest.html
FAIL*** : Live token = FAILED, did not match golden file token = PASSED<BR>
SUITE FAILED
348 requests.
344 passed.
4 failed.
0 skipped.
0 errors.
Thank you very much.
---------------
The Latka-based Watchdog tests currently live here:
http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/watchdog/
We've identified the source of 3 of the 4 remaining errors:
* GetHeader_01Test - HttpClient automatically sends a User-agent header,
while GTest does not. Solution: modify Latka (and possibly HttpClient) to
optionally suppress the User-agent.
* GetHeadersTest - The test tries to send two headers with the same name to
the server and confirm that two headers were received. Unfortunately, HTTP
also allows two separate headers with the same name to be combined into one
comma-delimited header, which HttpClient does automatically. So this test
is odd, because it tests for behaviour not guaranteed by HTTP. Solution:
alter Watchdog test to check for _either_ two headers _or_ one combined
header?
* HttpServletRequestWrapperGetHeaders - same as GetHeadersTest
* HttpServletRequestWrapperGetRequestURLTest - I haven't figured this one
out yet, but it also might be related to header issues. Solution: ?
I think we're well beyond the point of a working prototype and ready to
consider issues like test organization, distribution features, etc.
- Morgan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GTest to Latka conversion near completion
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Ryan Lubke" <Ry...@Sun.COM>
To: <wa...@jakarta.apache.org>
Sent: Thursday, July 18, 2002 8:29 PM
Subject: Re: GTest to Latka conversion near completion
> On Wed, 2002-07-17 at 13:11, Morgan Delagrange wrote:
> >
> > --- Ryan Lubke <Ry...@Sun.COM> wrote:
> > > On Wed, 2002-07-17 at 11:35, Morgan Delagrange
> > > wrote:
> >
<snip/>
> > > One thought pops to mind:
> > >
> > > - Reorganize the source (including package renaming
> > > for the test
> > > source) so that the test source isn't in a webapp
> > > like structure.
> >
> > Sounds interesting. I was thinking that we might
> > create a directory structure for the Latka tests
> > identical to the test packaging and change the servlet
> > redirects to also reflect the packaging. I would
> > think it would make maintenance easier if you knew
> > Servlet Mapping = Latka Test Dir = test class package.
>
> So I would think that with a reorg like this, that unless one
> person is performing all the conversion work in their sandbox and
> committing it all once complete, that we should probably have a
> release version of Watchdog so that people can still run the tests
> while the conversion process is in progress. Otherwise the nightly
> builds would prove to be frustrating as they most likely wouldn't work
> right for a bit.
>
> I guess another possibility is to target a particular nightly that
> people should use until the conversion is complete.
>
+1. :)
- Morgan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GTest to Latka conversion near completion
Posted by Ryan Lubke <Ry...@Sun.COM>.
On Wed, 2002-07-17 at 13:11, Morgan Delagrange wrote:
>
> --- Ryan Lubke <Ry...@Sun.COM> wrote:
> > On Wed, 2002-07-17 at 11:35, Morgan Delagrange
> > wrote:
>
> <snip/>
>
> > > The Latka-based Watchdog tests currently live
> > here:
> > >
> > >
> >
> http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/watchdog/
> > >
> > > We've identified the source of 3 of the 4
> > remaining errors:
> > >
> > > * GetHeader_01Test - HttpClient automatically
> > sends a User-agent header,
> > > while GTest does not. Solution: modify Latka (and
> > possibly HttpClient) to
> > > optionally suppress the User-agent.
> >
> > While it might be a good idea to have the ability to
> > enable/disable the
> > User-Agent request-header (maybe think about setting
> > the value of this
> > header as well to imitate Mozilla or IE clients),
> > The test could easily
> > be changed to look for a header that would never be
> > sent from a client.
> >
> > I think User-Agent was used, I believe, as GTest
> > didn't add support
> > headers when dispatching requests.
>
> Well, that sounds easier than making changes to Latka.
>
> > >
> > > * GetHeadersTest - The test tries to send two
> > headers with the same name to
> > > the server and confirm that two headers were
> > received. Unfortunately, HTTP
> > > also allows two separate headers with the same
> > name to be combined into one
> > > comma-delimited header, which HttpClient does
> > automatically. So this test
> > > is odd, because it tests for behaviour not
> > guaranteed by HTTP. Solution:
> > > alter Watchdog test to check for _either_ two
> > headers _or_ one combined
> > > header?
> >
> > No, I don't think the test should be altered as this
> > is a failure in the
> > Tomcat implementation of
> > HttpServletRequest.getHeaders(String). See the
> > following:
> >
> >
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526
>
> Ah good, so for the time being we can chalk it up as a
> Tomcat error and see how that bug shakes out.
>
> > >
> > > * HttpServletRequestWrapperGetHeaders - same as
> > GetHeadersTest
> > >
> > > * HttpServletRequestWrapperGetRequestURLTest - I
> > haven't figured this one
> > > out yet, but it also might be related to header
> > issues. Solution: ?
> >
> > Not sure about this one. Will have to investigate.
> >
> > >
> > >
> > > I think we're well beyond the point of a working
> > prototype and ready to
> > > consider issues like test organization,
> > distribution features, etc.
> >
> > One thought pops to mind:
> >
> > - Reorganize the source (including package renaming
> > for the test
> > source) so that the test source isn't in a webapp
> > like structure.
>
> Sounds interesting. I was thinking that we might
> create a directory structure for the Latka tests
> identical to the test packaging and change the servlet
> redirects to also reflect the packaging. I would
> think it would make maintenance easier if you knew
> Servlet Mapping = Latka Test Dir = test class package.
So I would think that with a reorg like this, that unless one
person is performing all the conversion work in their sandbox and
committing it all once complete, that we should probably have a
release version of Watchdog so that people can still run the tests
while the conversion process is in progress. Otherwise the nightly
builds would prove to be frustrating as they most likely wouldn't work
right for a bit.
I guess another possibility is to target a particular nightly that
people should use until the conversion is complete.
Thoughts?
>
> > >
> > > - Morgan
> > >
>
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Autos - Get free new car price quotes
> http://autos.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>
Re: GTest to Latka conversion near completion
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Ryan Lubke <Ry...@Sun.COM> wrote:
> On Wed, 2002-07-17 at 11:35, Morgan Delagrange
> wrote:
<snip/>
> > The Latka-based Watchdog tests currently live
> here:
> >
> >
>
http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/watchdog/
> >
> > We've identified the source of 3 of the 4
> remaining errors:
> >
> > * GetHeader_01Test - HttpClient automatically
> sends a User-agent header,
> > while GTest does not. Solution: modify Latka (and
> possibly HttpClient) to
> > optionally suppress the User-agent.
>
> While it might be a good idea to have the ability to
> enable/disable the
> User-Agent request-header (maybe think about setting
> the value of this
> header as well to imitate Mozilla or IE clients),
> The test could easily
> be changed to look for a header that would never be
> sent from a client.
>
> I think User-Agent was used, I believe, as GTest
> didn't add support
> headers when dispatching requests.
Well, that sounds easier than making changes to Latka.
> >
> > * GetHeadersTest - The test tries to send two
> headers with the same name to
> > the server and confirm that two headers were
> received. Unfortunately, HTTP
> > also allows two separate headers with the same
> name to be combined into one
> > comma-delimited header, which HttpClient does
> automatically. So this test
> > is odd, because it tests for behaviour not
> guaranteed by HTTP. Solution:
> > alter Watchdog test to check for _either_ two
> headers _or_ one combined
> > header?
>
> No, I don't think the test should be altered as this
> is a failure in the
> Tomcat implementation of
> HttpServletRequest.getHeaders(String). See the
> following:
>
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526
Ah good, so for the time being we can chalk it up as a
Tomcat error and see how that bug shakes out.
> >
> > * HttpServletRequestWrapperGetHeaders - same as
> GetHeadersTest
> >
> > * HttpServletRequestWrapperGetRequestURLTest - I
> haven't figured this one
> > out yet, but it also might be related to header
> issues. Solution: ?
>
> Not sure about this one. Will have to investigate.
>
> >
> >
> > I think we're well beyond the point of a working
> prototype and ready to
> > consider issues like test organization,
> distribution features, etc.
>
> One thought pops to mind:
>
> - Reorganize the source (including package renaming
> for the test
> source) so that the test source isn't in a webapp
> like structure.
Sounds interesting. I was thinking that we might
create a directory structure for the Latka tests
identical to the test packaging and change the servlet
redirects to also reflect the packaging. I would
think it would make maintenance easier if you knew
Servlet Mapping = Latka Test Dir = test class package.
> >
> > - Morgan
> >
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GTest to Latka conversion near completion
Posted by Ryan Lubke <Ry...@Sun.COM>.
On Wed, 2002-07-17 at 11:35, Morgan Delagrange wrote:
> Hi all,
>
> Last month, Ryan propsed converting the current Watchdog tests from GTest to
> Latka:
>
> http://marc.theaimsgroup.com/?l=watchdog-dev&m=102489712116217&w=2
>
> Ryan and I have made a lot of progress with the conversion effort. The
> current versions of Latka, HttpClient and Watchdog now produce only 4 errors
> (error report follows:
>
> ---------------
>
> ............................................................................
> ............................................................................
> .......................................FF...................................
> ......................................................F...........F.........
> ............................................
>
> http://localhost:8080/servlet-tests/GetHeader_01Test (GetHeader_01Test)
> REQUEST FAILED (10 millis)
> Returns null if the request does not have a header of that
> name,specified in the Java Servlet Pages Specification v2.3, Sec 14:
> EXPECTED TO MATCH GOLDEN FILE:
> \lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
> ServletRequest\GetHeader_01Test.html
> FAIL*** : Live token = FAILED, did not match golden file token = PASSED
>
> http://localhost:8080/servlet-tests/GetHeadersTest (GetHeadersTest)
> REQUEST FAILED (10 millis)
> Returns all the values of the specified request header as an Enumeration
> of String objects.,specified in the Java Servlet Pages Specification v2.3,
> Sec 14: EXPECTED TO MATCH GOLDEN FILE:
> \lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
> ServletRequest\GetHeadersTest.html
> FAIL*** : Live token = FAILED<BR>, did not match golden file token = PASSED
>
> http://localhost:8080/servlet-tests/hsreqw/HttpServletRequestWrapperGetHeade
> rsTest (HttpServletRequestWrapperGetHeadersTest)
> REQUEST FAILED (0 millis)
> Test for default behavior of this method to return getHeaders(String
> name) on the wrapped request object, specified in the Java Servlet Pages
> Specification v2.3, Sec 14: EXPECTED TO MATCH GOLDEN FILE:
> \lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
> ServletRequestWrapper\HttpServletRequestWrapperGetHeadersTest.html
> FAIL*** : Live token = FAILED, did not match golden file token = PASSED<BR>
>
> http://localhost:8080/servlet-tests/hsreqw/HttpServletRequestWrapperGetReque
> stURLTest (HttpServletRequestWrapperGetRequestURLTest)
> REQUEST FAILED (0 millis)
> Test for default behavior of this method to return getRequestURL() on
> the wrapped request object, specified in the Java Servlet Pages
> Specification v2.3, Sec 14: EXPECTED TO MATCH GOLDEN FILE:
> \lib\nightly\jakarta-watchdog-4.0\lib\servlet-golden\javax_servlet_http\Http
> ServletRequestWrapper\HttpServletRequestWrapperGetRequestURLTest.html
> FAIL*** : Live token = FAILED, did not match golden file token = PASSED<BR>
>
>
> SUITE FAILED
> 348 requests.
> 344 passed.
> 4 failed.
> 0 skipped.
> 0 errors.
>
>
> Thank you very much.
>
> ---------------
>
> The Latka-based Watchdog tests currently live here:
>
> http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/watchdog/
>
> We've identified the source of 3 of the 4 remaining errors:
>
> * GetHeader_01Test - HttpClient automatically sends a User-agent header,
> while GTest does not. Solution: modify Latka (and possibly HttpClient) to
> optionally suppress the User-agent.
While it might be a good idea to have the ability to enable/disable the
User-Agent request-header (maybe think about setting the value of this
header as well to imitate Mozilla or IE clients), The test could easily
be changed to look for a header that would never be sent from a client.
I think User-Agent was used, I believe, as GTest didn't add support
headers when dispatching requests.
>
> * GetHeadersTest - The test tries to send two headers with the same name to
> the server and confirm that two headers were received. Unfortunately, HTTP
> also allows two separate headers with the same name to be combined into one
> comma-delimited header, which HttpClient does automatically. So this test
> is odd, because it tests for behaviour not guaranteed by HTTP. Solution:
> alter Watchdog test to check for _either_ two headers _or_ one combined
> header?
No, I don't think the test should be altered as this is a failure in the
Tomcat implementation of HttpServletRequest.getHeaders(String). See the
following:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526
>
> * HttpServletRequestWrapperGetHeaders - same as GetHeadersTest
>
> * HttpServletRequestWrapperGetRequestURLTest - I haven't figured this one
> out yet, but it also might be related to header issues. Solution: ?
Not sure about this one. Will have to investigate.
>
>
> I think we're well beyond the point of a working prototype and ready to
> consider issues like test organization, distribution features, etc.
One thought pops to mind:
- Reorganize the source (including package renaming for the test
source) so that the test source isn't in a webapp like structure.
>
> - Morgan
>
>
> --
> 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>