Re: DNA TCK?

Leo Simons wrote:
> * Using proxy-based AOP or proxies themselves doesn't work (for example, 
> all setXXX in abstract components would need to be public, which is no 
> good for testing some types of IoC).
> 
> * Using bytecode modification requires control of the classloader (which 
> the TCK ideally should not require, as many containers like having that 
> control themselves)
> 
> * Using something like AspectJ seems a problem to me as well for much of 
> the same reasons.
> 
> Could you take a look and perhaps think of something better?
> 
> If not, things can still proceed but it's a lot of manual labor :/

Hi Leo,

I just joined this list for reasons pretty unrelated to IoC containers, but 
coincidentally, I might be able to provide some help.

I'll admit I'm not fully sure what you are trying to do, but it looks like you 
are basically trying to verify that a given method was invoked, even if you 
don't have control over all the entry points.

You might want to check out my project, VirtualMock 
(http://www.virtualmock.org), as it is designed to do exactly this.

It is based on AOP, so it may have some of the problems that you mention. 
However, I do support both major AOP implementations (AspectJ and AspectWerkz). 
  Between them, they support several approaches to the two basic types of 
bytecode modification (post-compilation, and class loader manipulation).

In VirtualMock, I've dealt with some of the issues you mention - by that, I mean 
the general problem of AOP bytecode manipulation interfering with other 
tools/applications.  However, when you drill down to the specific problem, it 
can often be overcome, especially if you have the choice of switching between 
the post-compile vs. classloader approach, without affecting the functionality 
of your framework.  VirtualMock is designed to allow just this.  Also, the folks 
at AspectWerkz are very committed to fixing this type of incompatibility if it 
is fixable.

Also, I am also planning to support dynamic-proxy based mocking in the future, 
which may be a viable third alternative in some situations, but this is not 
implemented yet and is probably a more long term.

As I mentioned in my other thread asking for IoC advice, I think that virtual 
mocks are a powerful concept, which have many potential uses that have not been 
considered yet.  This may be one of them.

In any case, it looks like the VirtualMock framework could save you some work in 
your project, or maybe not.  I'm very committed to making VirtualMock as 
flexible as possible for any use, not just Unit Testing.  So, I'll be very 
receptive to any suggestions you have on how to make it more flexible, or any 
specific problems you have with using it.  It's still in alpha and evolving, but 
the core functionality is all there and working.

Anyway, just thought I'd mention it since it seems like VirtualMock might be 
able to help you.  Let me know!

Good Luck,
Chad