myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <bdud...@mac.com>
Subject Re: cactus, cargo and testing on myfaces
Date Thu, 22 Sep 2005 16:28:25 GMT
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 <e.medina.m@gmail.com> wrote:
>
>> Yes, a good tutorial on the wiki would be great!
>>
>> 2005/9/22, Martin Marinschek <martin.marinschek@gmail.com>:
>>
>>> 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)
>>>
>> <alexander.jesse@credit-suisse.com> 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
>>>
>>>
>>
>>
>


Mime
View raw message