> -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED] > Sent: 10 December 2003 15:24 > To: Cactus Developers List > Subject: Re: [Proposal] Cactus2 architecture ideas > > Vincent, > > I think I'll need to see what a Cactus2 test case would actually look > like in code. I've done hardly nothing with AOP as of yet, so I can't > say I understand much of your proposal. The idea sounds interesting, > but I just can't imagine how it would work... > :-P
yep, I agree. I'm preparing a proof of concept ATM. Thanks -Vincent > > Cheers, > Chris > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > Am 09.12.2003 um 12:26 schrieb Vincent Massol: > > Hi Gang, > > > > I've been thinking a lot about Cactus these days and more specifically > > I've tried to create a Cactus SPI for test cases and connectors. I > > first > > refactored the existing code to make an SPI surface (this is what is > > currently in Cactus CVS). It looked good to me... until I started to > > think about how I would use it with an EjbTestCase for example. As > > Chris > > rightly said, I found that there are not many common points between the > > current XXXTestCase (where XXX = Servlet, Jsp, Filter) and an > > EjbTestCase. What would the beginXXX() method mean for EJBs? What would > > the endXXX() method mean? But even if it did mean something, what would > > the advantage of having an EjbTestCase? Answer: not much. If the EJB is > > remote, I can test it with a pure JUnit solution. If it is local then I > > can test it by doing a new MyEJB() and then use a mock context. So, > > what > > would be nice to have from a user point of view? > > > > The answer gave me another "vision" for Cactus' future. This new > > "vision" does not change the current "vision" I posted a few days ago. > > However it complements it and gives a potential new Cactus > > architecture. > > > > Here's what I think would be great for Cactus to provide: > > > > 1- a way to intercept calls made in any container. Why? Because for > > pure > > unit tests we already have mock objects. For functional tests we > > already > > have tools like HttpUnit, etc. However what we don't really have is a > > way to run functional tests *and* the ability to intercept any call > > happening in the container so that integration unit tests can be > > performed. There could be 2 ways of using this interception: > > * by intercepting the component entry point (whatever that is), the > > integration unit test could completely redirect the call flow and call > > any method for which a unit test is required > > * by preventing the calls to propagate to some layers (like the > > database layer). This allows testing some portion of the code in > > integration while isolating other parts. > > > > 2- a way to automate the whole process, i.e. start the container, > > deploy > > the components + tests, run the tests, stop the container. > > > > Actually all this is not new. I had started discussing it in 2002 if I > > recall correctly. However AOP and interception techniques were quite > > new > > at that time. > > > > What I'm proposing here is to restart this discussion as I really > > believe we can make something very powerful and more generic than the > > current architecture. > > > > A Cactus test would be the composition of a standard JUnit test > > (whatever the kind of test: HttpUnit, pure JUnit, whatever other JUnit > > extension) and an "Aspect" (i.e. the definition of interception points > > and what test logic to apply at those points). See the image attached > > for a 10,000 feet overview. > > > > Some further ideas: > > - the cactification would weave the test aspects into the runtime code > > - it might be best to reuse an existing AOP framework instead of using > > directly cglib/asm/bcel/etc as we need a generic interception API. > > - it might be best to use one of the Java-based framework (AspectWerkz > > for example) instead of a non-java based one (like AspectJ). I believe > > AspectJ is way more powerful but being non-java is not very friendly > > with development environments. > > - interception allows to unit test private methods easily. > > - the core framework will lighten a *lot* because: > > - we use existing JUnit extensions to provide the functional testing > > part. For example the whole HTTP connection stuff is left to HttpUnit > > instead of developing it ourself > > - we use an existing AOP framework for the interception part > > - we may or may not need to define standard pointcuts for different > > component APIs (servlets, taglibs, filters, ejbs, etc). > > - this would be the basis for Cactus 2.0 as the new architecture is > > completely new. > > - this would make Cactus much more open and flexible. Thus we could > > concentrate on offering end to end usability (automation of end to end > > integration unit testing). We start doing this in Cactus 1.5. We could > > push it a level further as a main advantage of Cactus. > > - I need to check what Chad has been doing lately with his AOP-testing > > framework (virtualmock) as this is going in the same direction. > > > > I'm getting really excited by all this stuff! :-) > > > > What do you think? > > > > Thanks > > -Vincent > > > > --------------------------------------------------------------------- > > 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]
