Hi Sean,
On Sep 22, 2005, at 7:25 AM, Sean Schofield wrote:
A few comments/questions on Bill's proposal...
The first is, do we want to go with Cactus, Cargo and Ant for this? I
don't have a problem with this although we've talked off and on about
using Maven for this at some point. Since our biggest Maven guru
(James Mitchell) is busy with some other stuff right now I say lets
stick with what we know.
Well Maven will build it but I don't think maven has in-container
capabilities. You can have maven deploy your cactus tests and run
them but maven is essentially a good way to reuse ant scripts, not an
in-container testing tool.
In a nutshell for those not familiar with these two tools.
Cactus -> JUnit in the container. From the client side I invoke a
Cactus test that is turned into a hit on the ServletRedirector
servlet (typically) that includes among other things the test class
and test method to invoke. On the server side the ServletRedirector
parses the request finds the test class to instantiate and the method
to invoke then using reflection invokes it and returns the result of
invoking the test.
Cargo -> Container management. Cargo starts and stops the container
with a bit of ant configuration. It is easy to delete and rebuild the
container stuff because Cargo takes care of all the file creation etc
that is required to get a valid instance of the container up and
running. For example with the patch I sent out Tomcat 5.5.9 is not
only started but a full deployment set of directories is created
(logs, webapps, work, etc) so that tomcat is running in a completely
different directory than my tomcat install directory. This is very
good because it can easily be deleted and recreated.
I don't think we will get anything from Maven along these lines other
than an easier way to fire up cactus and/or cargo.
One thing I think we should do is check out what Craig and the gang
are up to in Shale. They have all of these mock objects, etc that
they are using to test Shale. Lets make sure they haven't figured out
something already that we could use or easily adapt for our use.
Great idea. I'll try to dig around today and take a look at what is
there.
There are a lot of extra dependencies but they are only for the build,
not the actual usage of myfaces or tomahawk so I don't think that's
too big of a deal. One option is a separate target for downloading
the dependencies associated with the tests, but that might be a bit
much. That does mean, however, that in order to build from the source
you are required to supply your own local jars or use
download-dependencies and download some jars that you might not have
otherwise needed.
It is only compile time so should not be a big deal, but wanted to
point it out early so that it did not jump up on anyone.
@Bill,
You asked about breaking things with this new build. Here is a good
rule of thumb for you to verify this. Do an SVN checkout of
myfaces-current and then do a unit-test-all from current/build. Then
do clean-all from the same dir (to reset things). Then go to each
subproject and build indepedently (but in a logcial order b/c that is
still required). So api/build unit-test, share/build unit-test,
impl/build unit-test, etc. Also you should probably do the same for
dist-all at the top level and then dist at each of the subproject
levels. Just to make sure that "one build to rule them all" still
applies.
I will try the patch shortly when I get some much needed free time.
sean
On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote:
Yes, a good tutorial on the wiki would be great!
2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>:
I believe that there is no problem for us in adding any dependencies
as long as they are ASL licensed...
If you would write up some stuff on how to get started with testing,
it would be great - I hope we can then get the other developers
(including me) to write those tests as well.
regards,
Martin
On 9/22/05, Jesse Alexander (KBSA 21)
<[EMAIL PROTECTED]> wrote:
-----Original Message-----
With the TCK behind us (thanks again to all who worked so hard on
that) I figured it was a good time to work on getting cactus
tests in
place. My thinking behind Cactus is that we need to have the
ability
to do in container testing because some of the mock stuff is
just too
tedious. As background info I've been working on bug # 233 (empty
date for inputCalendar) and its just too complex to test all the
cases with mocks because of the amount of code that must be written
to setup the mock env.
-----/Original Message-----
Good to hear that. Developing my own components I also have the
problems
of testing. If we all join forces and know how on that, we can
come up
with a sample of testing components...
-----Original Message-----
So I set out to get a cactus test env that I could execute
container
side tests in and I've gotten a fair way there.
-----/Original Message-----
good to hear
-----Original Message-----
The Good:
1) Cactus gives us an alternative means to test (in the container)
2) Cargo integration will be a great way to build tests that
automatically invoke the example code on a wide range of containers
with each release. This will help us avoid problems with the
various
containers because of a lack of testing.
-----/Original Message-----
Cool. Maybe I should revive my ant-task for the Yourkit-profiler?
Right now I have a web-app (done with JSF) and a servlet (for use
with JMeter and similar) to control the Yourkit Profiler from
distance.
For an old version I once had also an ant-task... but I seem to
have
lost that source...
-----Original Message-----
The Bad:
1) more dependencies
2) we don't seem to have a ground swell of support for testing so
this all might be for nothing
-----/Original Message-----
Dependencies are only for build and testing? Is that so bad?
-----Original Message-----
What are you thoughts? Since introduction of JUnit I've not seen
any
additional tests being added to the mix. Its a huge task to get
test
coverage but I think its worth it, we will significantly reduce the
uncertainty in doing a release if we can get a good set of tests in
place.
-----/Original Message-----
JUnit is on e part of the game. But with presentation layer
stuff the
incontainer-testing is a must. The applications that depend on
Myfaces
may not need it (maybe they also need it...), but the confidence
the
incontainer test can give is important for future changes...
-----Original Message-----
I'm working on getting some more JUnit tests in place and would
love
to write up what is required if that would help others get started.
-----/Original Message-----
Way cool.
regards
Alexander
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
