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. 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.
- 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
- 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?
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]
