You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Brock Heinz <br...@nvisia.com> on 2004/05/18 07:00:40 UTC
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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: generating an index file to help with the ServletTestRunner
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Brock Heinz [mailto:brockh@nvisia.com]
> Sent: 25 May 2004 06:36
> To: Cactus Developers List
> Subject: Re: generating an index file to help with the
ServletTestRunner
>
> Vincent,
>
> >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.x
s
> >l
> >
> >
> I'm going to download the source some time this week and I'll send a
> PATCH when I knock it out. I'm thinking this would best fit with the
> cactifywar task.
Very cool! :-) Thanks,
>
>
> >>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?
> >
> Yep.
>
> >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.
> >
> >
> I'd actually prefer to place any resources on the wiki page. I'm not
> sure how much traffic my ISP will tolerate :)
Sure. Go ahead. The page is
http://wiki.apache.org/jakarta-cactus/UsefulCode
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: generating an index file to help with the ServletTestRunner
Posted by Brock Heinz <br...@nvisia.com>.
Vincent,
>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
>
>
I'm going to download the source some time this week and I'll send a
PATCH when I knock it out. I'm thinking this would best fit with the
cactifywar task.
>>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?
>
Yep.
>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.
>
>
I'd actually prefer to place any resources on the wiki page. I'm not
sure how much traffic my ISP will tolerate :)
Thanks,
Brock
>Thanks! Your help is much appreciated
>-Vincent
>
>
RE: generating an index file to help with the ServletTestRunner
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Brock Heinz [mailto:brockh@nvisia.com]
> 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:brockh@nvisia.com]
> >>Sent: 18 May 2004 07:01
> >>To: cactus-dev@jakarta.apache.org
> >>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: cactus-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: generating an index file to help with the ServletTestRunner
Posted by Brock Heinz <br...@nvisia.com>.
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.
>- 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.
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!
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
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:brockh@nvisia.com]
>>Sent: 18 May 2004 07:01
>>To: cactus-dev@jakarta.apache.org
>>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: cactus-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
RE: generating an index file to help with the ServletTestRunner
Posted by Vincent Massol <vm...@pivolis.com>.
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:brockh@nvisia.com]
> Sent: 18 May 2004 07:01
> To: cactus-dev@jakarta.apache.org
> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org