RE: PROPOSAL - Testing Framework
Hi Vincent, Any further news on Struts unit testing with J2EEUnit? Would you post a sample? I would like to see J2EEUnit in action testing the example that ships with Struts. Thanks for your time, RAP -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: 20 February 2001 09:45 To: [EMAIL PROTECTED] Subject: Re: PROPOSAL - Testing Framework +1 Great idea ! :) I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm committed to help you implement this suite of tests. I have already been implementing such a suite of tests for J2EEUnit itself and thus I know very well how to integrate it with Ant (actually I already have the build.xml that starts J2EEUnit tests). I have successfully created a build.xml file that run the tests on several servlet engines : Tomcat 3.1.1, Tomcat 3.2.1, Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ... That may be a good idea for Struts to run its unit tests on several Servlet engines. It is very easy to do ! I also have an Ant task that let you start any servlet engine in another thread, waits until it is finished starting and run the unit tests (it is still in CVS for the moment but I'll release a new 0.7 version this coming week end). Let me know where I can help. Also if you have any trouble to use J2EEUnit on any subject feel free to contact me and I'll help. Thanks. Note: You should use the 0.7 version as much as possible as in the previous version it was not possible to test any method that wrote in the Servlet output stream. It now works fine in version 0.7 (in CVS). Vincent Massol. - Original Message - From: "Rob Leland" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 19, 2001 7:36 PM Subject: PROPOSAL - Testing Framework I would like to add some additional Unit tests to the struts framework. These would be tests for struts itself, not end user code. My thoughts are that as struts evolves and new functionality is added we want to verify that other functionality is not broken, as code is changed and refactored. I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and J2EEUnit (J2eeunit.sourceforge.org). I am going to force myself to do this in an upcoming project at work, and believe it makes sense to do it in struts also. I am targeting the 1.1 release time period. If Unit testing is approved, some small set of tests may make it into the struts 1.0 release, again assuming people here vote for its inclusion. My initial thoughts for providing testing is to start with the private methods of struts starting with the struts.action package, then later develop tests for the public methods of struts.action. I didn't want to start another package until I finished the majority of the private methods, only because I would need to debug my unit tests, and only by developing tests for some of the private methods the public could I do this. Then other packages would follow : struts.upload, struts.util, struts.digester, struts.actions, struts.taglib.X In about that order, only because that would be a usefull order for me in the project I am working on. Infact, I only have plans to do struts.upload, and struts.util, and doubt I would have the time to produce tests for the other packages. Thoughts ? -Rob
Re: PROPOSAL - Testing Framework
I am now looking at Struts in order to write the test suite (I have only looked at build.bat and build.xml so far ...) and I have notice the following details that may need to be corrected/improved : 1- In build.bat, the CP variable does not define an XML parser. %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added. Or, is that voluntarily because you want to leave the choice to the developer to choose his one jaxp compliant parser ? Personnaly, I prefer to force it to a choice that will always work. I prefer to leave my CLASSPATH always empty because otherwise it creates lots of problems when you switch from one project to another ... 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and optional.jar) but in the jakarta-ant distribution that I got using CVS, the ant.jar and optional.jar are generated and put in dist\lib. 3- Is that an Apache choice not to bundle the needed external jars within your own project ? I would tend to prefer to bundle ant jars and servletapi jars for Struts because (a) they are only used to build struts, not for runtime and (b)otherwise the building of struts will fail or succeed depending on the state of these other projects, thus you might get lots of posts on the mailing list from persons trying to build Struts but failing just because they have a bad version of Ant for instance (I speak from experience as for J2EEUnit I tried several Ant release and I can tell you they were not all working, far from that, and I had to struggle to find the good one. At least I know that the one I bundle is going to work with no problem and from time to time I upgrade it. In other words I certify my app to work with such version. However if the enn developer want to use a newer/older version, he is free to try it ...). Thoughts ? (Sorry if this way of doing it has already been discussed at length ... :( ) 4- build.xml need more comments, better formatting and some minor additional refactorings (to my opinion). Am I allowed to do that ? 5- What do you think about creating a build directory where you put the files that are needed to run the build of struts. They would be : build.xml, build.bat, all Ant jars (that's only if you agree with point 3 of course ... :) ), maybe some other batch files to help start other targets from Windows. The output of the build will go in a directory named out/ for example (I have always found the name build/ for the output to be confusing. It means "a build" but also "to build" ...) 6- If you agree on point 3, creating a lib directory at the top level to put the servletapi jar would be a good idea. Also I need to put the j2eeunit + junit jars. Putting them in lib/ would be a good idea I think. 7- Why do you have a conf/ directory under src ? Wouldn't you prefer it to have at the top level (or is it a Jakarta requirement) ? Something like : jakarta-struts |_ out (generated by the build script) |_ build |_ conf |_ doc |_ src |_ example |_ share |_ test |_ web 8- I'd like to use the src/test/ directory to put the struts unit tests. What is the already existing test directory ? Was it done for that purpose ? 9- I'd like to create a test/ subdirectory un conf/ where I'll put all the configuration files needed for the struts unit tests. Is that ok? 10- The strategy I have followed with J2EEUnit for it's tests was to run the tests in the out/ directory, i.e. not deploy to the servlet engine install directory. I like to control the files that I generate. By being located under out/, they (a) are easy to clean up, (b) do not affect any other webapp running on my system, (c) I can use the setting I want for my servlet engine for the tests without affecting the main config of my servlet engine. I would suggest the following directory hierarchy : jakarta-struts |_ out |_ tests |_ tomcat-3.2 |_ conf |_ webapps |_ work |_ tomcat-4.0 |_ ... |_ resin-1.2 |_ ... |_ ... |_ conf |_ test |_ j2eeunit.properties |_ tomcat |_ testserver-3.2.xml |_ testserver-4.0.xml 11- Does Struts support only one servlet api at a time (like the 2.2 one) or is it your plan to support several, like 2.2 and 2.3 ? Please feel free to discard anything that I have said that does not fit your plan. I understand that I am new here ... However, I just wanted to let you know my thoughts in case I bring forward something that can improve Struts. Tell me what you think of these and tell me how I have to proceed for building the test suite ? Do I change the files and send the to you by email ? What can I apply from the above mentionned points ? Is there a CVS branch that I should work on instead of the main one ? Thanks. Vincent.
Re: PROPOSAL - Testing Framework
Vincent Massol wrote: I am now looking at Struts in order to write the test suite (I have only looked at build.bat and build.xml so far ...) and I have notice the following details that may need to be corrected/improved : Hello Vincent, Sorry for the slow response ... I was really focused yesterday on getting the beta out. Now we can start planning next steps. 1- In build.bat, the CP variable does not define an XML parser. %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added. Or, is that voluntarily because you want to leave the choice to the developer to choose his one jaxp compliant parser ? Personnaly, I prefer to force it to a choice that will always work. I prefer to leave my CLASSPATH always empty because otherwise it creates lots of problems when you switch from one project to another ... My preference has always been to allow people to choose their own tools -- such as their own version of Ant, their own XML parser, their own servlet API version, and so on -- rather than force these decisions. After all, Struts will be used in applications that have all manner of dependencies on different versions of these things. On Ant in particular, I would actually prefer us to run Ant via "$ANT_HOME/bin/ant" (Unix) or "%ANT_HOME%\bin\ant.bat" (Windows). That way, we can let Ant itself worry about the changing directory structures required by different versions of Ant. In addition, modern versions of "ant" and "ant.bat" let you define system properties via "~/.antrc" (Unix) or "%HOME%\antrc_pre.bat" and "%HOME%\antrc_post.bat" (Windows). 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and optional.jar) but in the jakarta-ant distribution that I got using CVS, the ant.jar and optional.jar are generated and put in dist\lib. Switching to $ANT_HOME/bin/ant will take care of this kind of thing. 3- Is that an Apache choice not to bundle the needed external jars within your own project ? Different Apache subprojects do it differently -- this is my choice (and I'm probably in the minority here). I use quite a few open source projects, and the number of copies of ant.jar and xerces.jar on my hard drive is pretty disgusting. I would tend to prefer to bundle ant jars and servletapi jars for Struts because (a) they are only used to build struts, not for runtime and (b)otherwise the building of struts will fail or succeed depending on the state of these other projects, thus you might get lots of posts on the mailing list from persons trying to build Struts but failing just because they have a bad version of Ant for instance (I speak from experience as for J2EEUnit I tried several Ant release and I can tell you they were not all working, far from that, and I had to struggle to find the good one. At least I know that the one I bundle is going to work with no problem and from time to time I upgrade it. In other words I certify my app to work with such version. However if the enn developer want to use a newer/older version, he is free to try it ...). Thoughts ? (Sorry if this way of doing it has already been discussed at length ... :( ) It hasn't been discussed on STRUTS-DEV, so it's probably worth talking about. How do folks feel about this? Was the pain of having to download the prerequisite packages worth the ability to use whatever versions you preferred? 4- build.xml need more comments, better formatting and some minor additional refactorings (to my opinion). Am I allowed to do that ? Yes. Once we agree on a path, any of the docs or build scripts are fair game, along with the code :-). 5- What do you think about creating a build directory where you put the files that are needed to run the build of struts. They would be : build.xml, build.bat, all Ant jars (that's only if you agree with point 3 of course ... :) ), maybe some other batch files to help start other targets from Windows. The output of the build will go in a directory named out/ for example (I have always found the name build/ for the output to be confusing. It means "a build" but also "to build" ...) I personally prefer the build.xml and associated scripts to be in the top-level directory so you do not have to go hunting for them. Currently, the 'build" directory is an *output* of the Struts build process, rather than an input. We'd have to change that (for example, some subprojects use "target" for their destinations). In your scenario below, it looks like this should be changed to "out". 6- If you agree on point 3, creating a lib directory at the top level to put the servletapi jar would be a good idea. Which version? Right now, Struts requires only servlet 2.2 / JSP 1.1 APIs, but my daily work on Tomcat 4.0 requires me to use the servlet 2.3 / JSP 1.2 servlet.jar file. This is the kind of problem you run into by forcing a choice on the developer :-). . Also I need to put the j2eeunit + junit jars. Putting them in lib/ would be a good idea I
Re: PROPOSAL - Testing Framework
"Craig R. McClanahan" wrote: Rob Leland has volunteered to take the lead on this, but I don't know if anything specific has happened yet. Not only am I willing to Lead but to follow, since Vince obviously has MUCH more experience with J2EEUnit testing than me. I have a handle on JUnit, but not J2EEUnit , ... Yet :). Nothing has been put in place, I have started looking at the action classes had hoped to get a few tests in by version 1.0, with the bulk of the tests for version 1.1. So Vince what would you propose for directory structures, organizing tests ? It looked like you had some good suggestions yesterday. -Rob
Re: PROPOSAL - Testing Framework
Give me until tomorrow and I'll come up with a structure, organization, and some tests proposals ... :) Thanks. Vincent. - Original Message - From: "Rob Leland" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 9:47 PM Subject: Re: PROPOSAL - Testing Framework "Craig R. McClanahan" wrote: Rob Leland has volunteered to take the lead on this, but I don't know if anything specific has happened yet. Not only am I willing to Lead but to follow, since Vince obviously has MUCH more experience with J2EEUnit testing than me. I have a handle on JUnit, but not J2EEUnit , ... Yet :). Nothing has been put in place, I have started looking at the action classes had hoped to get a few tests in by version 1.0, with the bulk of the tests for version 1.1. So Vince what would you propose for directory structures, organizing tests ? It looked like you had some good suggestions yesterday. -Rob
Re: PROPOSAL - Testing Framework
+1 Great idea ! :) I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm committed to help you implement this suite of tests. I have already been implementing such a suite of tests for J2EEUnit itself and thus I know very well how to integrate it with Ant (actually I already have the build.xml that starts J2EEUnit tests). I have successfully created a build.xml file that run the tests on several servlet engines : Tomcat 3.1.1, Tomcat 3.2.1, Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ... That may be a good idea for Struts to run its unit tests on several Servlet engines. It is very easy to do ! I also have an Ant task that let you start any servlet engine in another thread, waits until it is finished starting and run the unit tests (it is still in CVS for the moment but I'll release a new 0.7 version this coming week end). Let me know where I can help. Also if you have any trouble to use J2EEUnit on any subject feel free to contact me and I'll help. Thanks. Note: You should use the 0.7 version as much as possible as in the previous version it was not possible to test any method that wrote in the Servlet output stream. It now works fine in version 0.7 (in CVS). Vincent Massol. - Original Message - From: "Rob Leland" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 19, 2001 7:36 PM Subject: PROPOSAL - Testing Framework I would like to add some additional Unit tests to the struts framework. These would be tests for struts itself, not end user code. My thoughts are that as struts evolves and new functionality is added we want to verify that other functionality is not broken, as code is changed and refactored. I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and J2EEUnit (J2eeunit.sourceforge.org). I am going to force myself to do this in an upcoming project at work, and believe it makes sense to do it in struts also. I am targeting the 1.1 release time period. If Unit testing is approved, some small set of tests may make it into the struts 1.0 release, again assuming people here vote for its inclusion. My initial thoughts for providing testing is to start with the private methods of struts starting with the struts.action package, then later develop tests for the public methods of struts.action. I didn't want to start another package until I finished the majority of the private methods, only because I would need to debug my unit tests, and only by developing tests for some of the private methods the public could I do this. Then other packages would follow : struts.upload, struts.util, struts.digester, struts.actions, struts.taglib.X In about that order, only because that would be a usefull order for me in the project I am working on. Infact, I only have plans to do struts.upload, and struts.util, and doubt I would have the time to produce tests for the other packages. Thoughts ? -Rob
Re: PROPOSAL - Testing Framework
On the contact info for testing could you change the contact email address from: [EMAIL PROTECTED] to : [EMAIL PROTECTED] That way I can sort out email easier. -Rob
RE: PROPOSAL - Testing Framework
+1 We are already using the ant 'junit' task in some of our project, and it works really well. One thing we have found is that our tests really end up being split into two kinds: unit, and integration. We classify as 'unit' those tests which can run on the code as compiled in place in the build directory. These tests typically stress some smaller piece of code, often simulating some of the interfaces the code normally interacts with. We classify as integration those tests which require something to be deployed into a running server somewhere. While this can and should be automated, it is a different level of testing... Both kinds of tests are very useful... -Original Message- From: Rob Leland [mailto:[EMAIL PROTECTED]] Sent: February 19, 2001 1:37 PM To: [EMAIL PROTECTED] Subject: PROPOSAL - Testing Framework I would like to add some additional Unit tests to the struts framework. These would be tests for struts itself, not end user code. My thoughts are that as struts evolves and new functionality is added we want to verify that other functionality is not broken, as code is changed and refactored. I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and J2EEUnit (J2eeunit.sourceforge.org). I am going to force myself to do this in an upcoming project at work, and believe it makes sense to do it in struts also. I am targeting the 1.1 release time period. If Unit testing is approved, some small set of tests may make it into the struts 1.0 release, again assuming people here vote for its inclusion. My initial thoughts for providing testing is to start with the private methods of struts starting with the struts.action package, then later develop tests for the public methods of struts.action. I didn't want to start another package until I finished the majority of the private methods, only because I would need to debug my unit tests, and only by developing tests for some of the private methods the public could I do this. Then other packages would follow : struts.upload, struts.util, struts.digester, struts.actions, struts.taglib.X In about that order, only because that would be a usefull order for me in the project I am working on. Infact, I only have plans to do struts.upload, and struts.util, and doubt I would have the time to produce tests for the other packages. Thoughts ? -Rob
