> -----Original Message----- > From: Brock Heinz [mailto:[EMAIL PROTECTED] > Sent: 18 May 2004 16:57 > To: Cactus Developers List > Subject: Re: generating an index file to help with the ServletTestRunner > > Hi Vincent, > > Vincent Massol wrote: > > >Hi Brock, > > > >Thanks for posting here! Let me try to repeat with my own words your use > >case to ensure I've understood. You're interested in using the servlet > >test runner to allow users to selectively run a subset of tests when > >they want. > > > Exactly. > > >This is to be compared with the <cactus> and <junitreport> > >Ant tasks which also do the same thing. > > > >I've listed below the advantages of using the <cactus> task. > > > >Pros of <cactus>/<junitreport>: > > > >- it's automated and can be run as part of a continuous build (say every > >2 hours). With the Servlet Test Runner you don't know when the code is > >broken as you have to explicitely click on *all* links to know if the > >code is still working. > > > > > > > I agree. For our QA environment we have our application built / > deployed on a nightly basis. Part of that nightly build does include > running regression tests (although we don't generate the JUnit reports). > > >- it supports running selectively tests. For example, if you're running > >Ant, you can simply have: > > > ><target name="cactus"> > >[...] > > > ><cactus> > >[...] > > <batchtest> > > <fileset dir="${src.cactus.dir}"> > > <include name="${cactus.includes}"/> > > <exclude name="${cactus.excludes} "/> > > </fileset> > > </batchtest> > ></cactus> > > > >Then you simply type: > > > >ant -Dcactus.includes=**/MyTestCase.java cactus > > > > > I agree - this is a great way to dynamically pass your test cases to > your build, but unfortunately the majority of our developers aren't very > ANT savvy :( Typically our builds are executed via a windows cmd script > that delegates to ANT passing whatever parameters necessary.
This also works... :-) Just create as many cmd script as you like putting things like the following in it: start ant -Dcactus.includes=**/MyTestCase.java cactus You could even ask the user to enter the name of the tests he wants to run. You could pop up a graphical combo box, etc. You could use the Ant <input> task to ask for input, etc. > > >- it automates starting/stopping the container + deploying the tests > >into the container > > > >Now, I'm probably missing some stuff... :-) Do you think you could do > >the same and list the pros of using the Servlet Test Runner vs using the > ><cactus> task? > > > > > > > Nope - you're pretty much right on :) Although I can see that the > scenario you just described above fits perfectly in most cases - there > are certain instances where it is desirable to selectively run certain > tests. For instance, we have written test cases that invoke web > services that are located on another machine. Now although executing > these tests are not dependent on a J2EE container, Cactus' servlet test > runner gives us a great medium to 'pick and choose' which tests to invoke. Sure. If you like it, please continue to use it! :-) > > Anyhow, the more that I think about the scope of Cactus and the task > that I have created, I can see that maybe it's not quite a good fit. > Thanks for the feedback, and keep up the good work! Cool. What would be *very* nice I think is to plug your code in the ServletTestRunner so that if you call the ServletTestRunner with no parameter for example, it displays a list of all existing test suites so that users can click on them. If you could provide this, I think we could definitely commit it as part of the main cactus codebase. It should be easy to write. Some ideas: - http://[...]/context/ServletTestRunner?format=xml|html (defaults to html). - use a stylesheet to convert the xml to html - allow users to provide their own stylesheet: http://[...]/context/ServletTestRunner?format=xml&stylesheet=whatever.xs l > > If anyone is interested in taking a look at the task, I've posted the > code and a snippet of a build file here. > > http://brockheinz.dyndns.org/cactus/index.html Excellent. Do you plan to keep it at this address? If so, I'll link it from the Cactus resource page. Another possibility is to create a contrib area on the Cactus wiki where you could put the code. Let me know which you prefer. Thanks! Your help is much appreciated -Vincent > > Thanks, > Brock > > > >Thanks > >-Vincent > > > >PS: I'm really not against using the Servlet Test Runner; it's just that > >I haven't found so far any compelling reason to use it instead of the > ><cactus> task. It's good to get started with Cactus but past this stage > >people usually turn towards the <cactus> task to automate the execution > >of tests. > > > > > > > >>-----Original Message----- > >>From: Brock Heinz [mailto:[EMAIL PROTECTED] > >>Sent: 18 May 2004 07:01 > >>To: [EMAIL PROTECTED] > >>Subject: generating an index file to help with the ServletTestRunner > >> > >>Hey All, > >> > >>I saw a 'The Server Side' post today about Cactus 1.6.1 being released > >>and it reminded me of an ANT task that I wrote some time back. > >>Basically the task generates an index file with links pointing to > >>Cactus' ServletTestRunner (of course passing the fully qualified > >>TestCase name as a request parameter), thus allowing a user to easily > >>execute a TestCase/Suite via the browser. The ANT task traverses a > >>specified source directory, and using reflection, it alphabetically > >>separates all of the TestCases from the TestSuites. This provided > >>useful to my current client because we found that running our full > >>regression suite, and then generating the JUnit reports wasn't > >> > >> > >conducive > > > > > >>to our development environment - it took too darn long. Also, it > >> > >> > >wasn't > > > > > >>very practical for us to modify the build file so that different > >>TestCases / Suites could be run as needed. Deploying a Cactus > >>Application along side our application made the most sense. We found > >>that it encouraged our developers to write tests, and it allowed > >>pseudo-technical project managers to execute tests (when the Cactus > >> > >> > >app > > > > > >>is deployed on our QA servers) to monitor development progress. Now > >> > >> > >I'm > > > > > >>not sure whether our case is unique, and this ANT task that generates > >>the index page wouldn't be useful, but if the group finds it is - I'd > >> > >> > >be > > > > > >>happy to contribute it. Anyone have any thoughts? > >> > >>Thanks, > >>Brock Heinz > >> > >> > >>PS. Below is 'The Server Side' thread between Vincent and myself: > >> > >>---------------------------------------- > >>Hey All, > >> > >>While recently working with a client we had a scenario where we were > >>building and deploy an EAR file on a nightly basis. This build > >> > >> > >consisted > > > > > >>of the typical JUnit regression tests being run, but we needed > >> > >> > >something > > > > > >>more. We wanted to have the ability to run our unit tests (or > >> > >> > >regression > > > > > >>tests) via the browser and we wanted to immediately see the results. > >>With Cactus' ServletTestRunner, we were able to (relatively easily) > >>create a test WAR that is deployed along side our nightly EAR file. > >> > >>Originally just the developers were executing the tests via the > >> > >> > >browser, > > > > > >>and we just needed to remember the TestCase's names (along with > >>packages) and we would pass them to the ServletTestRunner via the > >>'suite' request parameter. No big deal. But, as the project evolved > >> > >> > >and > > > > > >>more people wanted to execute the tests, this scenario didn't fit > >> > >> > >will. > > > > > >>So then we created an index file that was to be deployed with the test > >>WAR. Basically we had to add by hand the links to execute the given > >>tests as they were written. This was fine, but we quickly realized > >> > >> > >that > > > > > >>this could be automated with our build. So after spending a few hours > >>writing an ANT task, we were able to generate an index Cactus file > >> > >> > >that > > > > > >>showed links to all of our Unit and Regression tests. An static HTML > >>example of this can be seen here: > >> > >>http://brockheinz.dyndns.org/cactus/cactus.html > >> > >>Since this was done some time ago, I'm not sure if the folks at Cactus > >>have developed something similar (or if it even already exists :) But > >> > >> > >if > > > > > >>anyone finds this useful, I'd like to contribute it to the community. > >>Anyone have any thoughts on this? > >> > >>Brock > >> > >> > >>------------------------------ > >> > Since this was done some time ago, I'm not sure if the folks at > >>Cactus have > >> > developed something similar (or if it even already exists :) But if > >>anyone finds this useful, > >> > I'd like to contribute it to the community. Anyone have any > >> > >> > >thoughts > > > > > >>on this? > >> > >>We value all feedbacks! If you're interested in getting this > >> > >> > >integrated > > > > > >>we could start a discussion on the Cactus mailing list. I'd like to > >>understand more about your use case and why you think using the > >> > >> > >provided > > > > > >><cactus> task + the <junitreport> cannot fill the bill. > >> > >>Thanks! > >> > >> > >>--------------------------------------------------------------------- > >>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]
