Re: Test Case Exception Throwing style (Re: Cactus tests)
James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
To clarify my own statement: the cactus tests in maven run using the Tomcat installed in the location defined in build.properties under the property name tomcat.home.41 The Maven cactus plugin doesn't seem to support Tomcat 3. I guess we could work those ant tasks into the maven.xml file more or less as they are now. I'll commit all that stuff as soon as I'm official. Joe Ted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. -Ted. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Personally, I could live with running with Cactus tests just against TC4.1, so long as we were still testing the sample applications under TC3.3 before a release. When I get the release notes caught up, I'm planning to do a suite of Canoo Webtests for the example applications, which will be easy to run against any given container. -Ted. Joe Germuska wrote: To clarify my own statement: the cactus tests in maven run using the Tomcat installed in the location defined in build.properties under the property name tomcat.home.41 The Maven cactus plugin doesn't seem to support Tomcat 3. I guess we could work those ant tasks into the maven.xml file more or less as they are now. I'll commit all that stuff as soon as I'm official. Joe Ted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
On Thu, 11 Dec 2003, Ted Husted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. I'd be +0 on dropping Tomcat 4.0 testing. However, we might want to start testing against Tomcat 5.0, now that a stable release is available: http://jakarta.apache.org/site/news.html#20031203.1 -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Essentially, it would remove the need to click-thru the example applications by hand. These are UI tests directly against the HTML pages. Typically, these types of tests are delicate, but WebTest is scripted with a XML file, so in practice they are relatively easy to maintain. Martin Cooper wrote: On Thu, 11 Dec 2003, Ted Husted wrote: Personally, I could live with running with Cactus tests just against TC4.1, so long as we were still testing the sample applications under TC3.3 before a release. When I get the release notes caught up, I'm planning to do a suite of Canoo Webtests for the example applications, which will be easy to run against any given container. I'm not familiar with Canoo (but always interested in hearing about good new testing tools!). Can you give a quick outline of what it would add to our Cactus + *Unit tests? -- Martin Cooper -Ted. Joe Germuska wrote: To clarify my own statement: the cactus tests in maven run using the Tomcat installed in the location defined in build.properties under the property name tomcat.home.41 The Maven cactus plugin doesn't seem to support Tomcat 3. I guess we could work those ant tasks into the maven.xml file more or less as they are now. I'll commit all that stuff as soon as I'm official. Joe Ted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Martin Cooper wrote: I'd be +0 on dropping Tomcat 4.0 testing. However, we might want to start testing against Tomcat 5.0, now that a stable release is available: http://jakarta.apache.org/site/news.html#20031203.1 If the policy is that Struts 1.x supports 2.2/1.2 and later, then I suppose we should. Though, I'm not sure if we should hold a release for a 2.4/2.0 issue. So I'd say the Tomcat 5 tests would be gump-grade, early warning tests. Since we are standards-orientated, we should only be testing against the referenence implemetation for each specification we support. I'd like to drop the TC4.0 tests since it is not the current reference implementation. From our perspective, it's now just another container, like Jetty, Resin, or the Web*'s. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Quoting Martin Cooper [EMAIL PROTECTED]: On Thu, 11 Dec 2003, Ted Husted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. I'd be +0 on dropping Tomcat 4.0 testing. I'm +1 on that -- 4.0 isn't actively supported any longer by the Tomcat folks. However, we might want to start testing against Tomcat 5.0, now that a stable release is available: http://jakarta.apache.org/site/news.html#20031203.1 I'm definitely +1 on that. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
On Tue, 9 Dec 2003, Joe Germuska wrote: Rob Leland wrote: For what it's worth, I've got it passing 71/97 tests clear, and the rest fall into two categories: 19 with failures because the context-path of the test app is hardcoded as test and the plugin uses struts-cactus, and 7 that have to do with cookie values. If anyone has any clever ideas for the simplest way to extract the context path The context path used for the test is stored in the build.properties file. Couldn't those properties be read in by the unit tests ? Right now they are used to modify the server.xml file by using ant filtering while copying. Also if you look at the CVS history of those files with a hard coded 'test' context you'll probably see the path change from /test/xyz/abc.jsp - /xyz/abc.jsp - /test/xyz/abc.jsp Well, I just changed the string literal in response.encodeURL to the concatenation of request.getContextPath() and the context relative URL. That worked, and seems decently flexible. So now the only mystery is why cookies don't seem to be set in my cactus environment (the common problem in the remaining tests which don't pass.) Wish I could shed some light on this, but I haven't been able to figure out what changed in our configuration to cause the cactus tests to fail for any of the tests that I wrote. So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: ... ... [junit] Testcase: testMessageTag2ArgNameNoScopeDefaultBundle_fr took 0.02 sec [junit] Testcase: testMessageTag2ArgNameApplicationScopeDefaultBundle_fr took 0 sec [junit] Caused an ERROR [junit] Address already in use: connect [junit] java.net.BindException: Address already in use: connect [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) ... ... If I close down a few extract programs it will get a bit farther, which leads me to assume that it is a memory issue for my machine. When attempting to maven on a clean checkout, I get this: ... ... test:test: [junit] dir attribute ignored if running in the same VM [junit] Running org.apache.struts.action.TestDynaActionForm [junit] Tests run: 44, Failures: 0, Errors: 0, Time elapsed: 0.19 sec [junit] dir attribute ignored if running in the same VM [junit] Running org.apache.struts.action.TestDynaActionFormClass [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.12 sec [junit] dir attribute ignored if running in the same VM [junit] Running org.apache.struts.config.TestActionConfigMatcher [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.16 sec [junit] dir attribute ignored if running in the same VM [junit] Running org.apache.struts.config.TestModuleConfig junit.framework.AssertionFailedError: Got an input stream for struts-config.xml at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at org.apache.struts.config.TestModuleConfig.testParse(TestModuleConfig.java:163) ... ... Oh well, wish I could help more. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Wish I could shed some light on this, but I haven't been able to figure out what changed in our configuration to cause the cactus tests to fail for any of the tests that I wrote. We upgraded the version of Cactus. It was passing with 1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Rob Leland wrote: For what it's worth, I've got it passing 71/97 tests clear, and the rest fall into two categories: 19 with failures because the context-path of the test app is hardcoded as test and the plugin uses struts-cactus, and 7 that have to do with cookie values. If anyone has any clever ideas for the simplest way to extract the context path The context path used for the test is stored in the build.properties file. Couldn't those properties be read in by the unit tests ? Right now they are used to modify the server.xml file by using ant filtering while copying. Also if you look at the CVS history of those files with a hard coded 'test' context you'll probably see the path change from /test/xyz/abc.jsp - /xyz/abc.jsp - /test/xyz/abc.jsp Well, I just changed the string literal in response.encodeURL to the concatenation of request.getContextPath() and the context relative URL. That worked, and seems decently flexible. So now the only mystery is why cookies don't seem to be set in my cactus environment (the common problem in the remaining tests which don't pass.) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association smime.p7s Description: S/MIME cryptographic signature
Re: Test Case Exception Throwing style (Re: Cactus tests)
Comments in line. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, December 8, 2003 09:56 PM To: 'Struts Developers List' Subject: Test Case Exception Throwing style (Re: Cactus tests) I would suggest that the proper behavior here is to throw the exception and let JUnit deal with it as an error rather than a failure. This puts the actual error in the test report, which makes it a lot easier to solve the problem. +1 sounds good. For what it's worth, I've got it passing 71/97 tests clear, and the rest fall into two categories: 19 with failures because the context-path of the test app is hardcoded as test and the plugin uses struts-cactus, and 7 that have to do with cookie values. If anyone has any clever ideas for the simplest way to extract the context path The context path used for the test is stored in the build.properties file. Couldn't those properties be read in by the unit tests ? Right now they are used to modify the server.xml file by using ant filtering while copying. Also if you look at the CVS history of those files with a hard coded 'test' context you'll probably see the path change from /test/xyz/abc.jsp - /xyz/abc.jsp - /test/xyz/abc.jsp Why this occured I couldn't tell you. without using the tags which are being tested, I'm all ears...the cookie thing is totally baffling at the moment. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
