Once again the image has been stripped... :-( Here it is:
http://cvs.apache.org/~vmassol/cactus_new/cactus_new_architecture.JPG Thanks -Vincent > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 09 December 2003 12:27 > To: 'Cactus Developers List' > Subject: [Proposal] Cactus2 architecture ideas > > 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]
