Re: DNA TCK?

Leo Simons wrote:
> Chad Woolley wrote:
>>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.
> 
> 
> I just have a lot of scepticism to overcome here. If I use 
> VirtualMock+AspectWerkz to create mocks that I put inside an environment 
> that modifies the mocks using AspectJ (or the other way around), will it 
> work? Have you tried things like that? Has anyone? Will it still work 6 
> months from now?
> 
> What about a container that uses java proxies, or worse, a custom 
> BCEL-based or CGLIB-based proxy generator? (ie,
> 
> http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon/fortress/container/src/impl/org/apache/avalon/fortress/impl/factory/BCELWrapperGenerator.java?content-type=text%2Fplain&rev=1.12
> http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon/fortress/container/src/impl/org/apache/avalon/fortress/impl/factory/BCELCodeGenerator.java?content-type=text%2Fplain&rev=1.6
> 
> )
> 
> Not that I place any more trust in being able to combine those with my 
> custom java-proxy based code, but when errors occur there I'll have a 
> rather short and familiar stack trace to look at.

It is really dependent on the situation.

One example is the patch to EasyMock which allows mocking of classes, not just 
interfaces, which uses CGLIB.  I use this patch to unit test my own VirtualMock 
code.  I had a lot of problems using this patch in conjunction with AspectWerkz, 
but not with AspectJ.  Jonas at AspectWerkz finally looked into it, and found it 
was something wrong that cglib was doing, and got the cglib developer to agree 
to fix it in the next release.

So, the bottom line, this is brave new bleeding-edge territory, and has problems 
  because I think this is, in general, stuff the creators of java didn't 
envision.  Supposedly when JDK 1.5 is available, it will include features to 
standardize and eliminate a lot of these problems, but I haven't researched the 
details on that.

It's probably likely that you will encounter some problems with compatibility 
with some tools.  However, I've tried to account for that, because you can 
choose to exclude certain classes, packages, etc. from being woven (using 
wildcards).  I have used this to get around several compatibility problems. 
This may be a valid approach for some of the problems you might encounter.

> I'm definately going to try it out at some point. For reference, here's 
> a sample of what I would want to do with VirtualMock (currently not 
> knowing much about its api):
> 
>                                                             // fragments
> public abstract class AbstractContainerTestCase
>    extends AbstractMockTestCase
> {
>    public MockService m_mockService;
> 
>    public void setUp() throws Exception
>    {
>      super.setUp();
> 
>      m_mockService = super.getMockService();
>    }
> 
>    public abstract Homer getHomer(); // implemented in subclass;
>      // by contract the created instance must be a subclass of
>      // AbstractHomer, which is supplied by the TCK. How the
>      // subclass creates the instance, or exactly what happens to it...
>      // I don't know, but I want to take a look at what happened later
> 
>    public void testHomerCreatedAsHeShouldHaveBeen()
>    {
>      final Homer homer = getHomer();
>      final Recorder recorder = m_mockService.getRecorder( homer );
> 
>      assertNoExceptionsWereThrown( recorder );
>      assertWasFirstMethodCall( recorder, "setMarge" );
>      assertNoNullArguments( recorder, "setMarge" );
>      assertWasMethodCallNumberInRange( 0, 5, recorder, "setBart" );
>      assertNoNullArguments( recorder, "setBart" );
>      assertWasLastMethodCall( recorder, "initialize" );
>      assertWasNotCalled( recorder, "setSomeoneFamous" );
> 
>    }
> }
> 
> Those assertions would take a look at what the recorder recorded, and 
> fail with meaningful error messages. An example would be:
> 
> assertNoExceptionsWereThrown( Recorder recorder )
> {
>    Invocation[] invocations = recorder.getRecordedInvocations();
>    for( int i = 0; i < invocations.lengthl i++ )
>    {
>      Throwable t = invocation.getThrowable();
>      if( t != null )
>      {
>        t.printStackTrace();
>        fail(
>          "we recorded that the method " + invocation.getMethod() +
>          " of the " + invocation.getTarget().getClass().getName() +
>          " instance your provided threw an exception: "
>          + t.getMessage() );
>      }
>    }
> }
> 
> I guess most of these methods are pretty domain-specific.

It looks like, in general, you just want to gather information about the calls 
that were made on the Recorder class.  VirtualMock can definitely do that.  Some 
of the specific stuff you are asserting, especially the ordering, may not be 
fully supported by the API yet, but that is what I am working on now.  I am 
currently investigating if I can reuse the jMock API for specifying 
expectations, which is a lot more mature and robust than what I currently have 
in VirtualMock.

However, these specific expectations are, to use the jMock term, "sugar" on the 
API.  The core functionality of intercepting the calls at the class level and 
grabbing info from them currently exists and works fine in VirtualMock.  If you 
give feedback on how you would like the API to be more flexible, we can work on 
it, or you can extend the expectation framework to do stuff that is specific to 
your tool.

>>Anyway, just thought I'd mention it since it seems like VirtualMock 
>>might be able to help you.  Let me know!
> 
> 
> will do. You want further feedback on this list or somewhere else?
> 

Whatever you think.  I'm the newbie here, so I'll let you decide!  You can use 
the virtualmock admin ID to mail me directly if you want, which is linked at the 
bottom of all the VirtualMock webpages (spamproofed there, so I'm not going to 
type it here in plaintext).

Thanks,
Chad