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]
