Contribution to jMock (injection Mocks at constructor calls)

[Sebastian Sickelmann-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

HI,

 

I have created a small extension for injecting jMock at constructor-call.
I plan to contribute this to jmock, if it fits to the main goals of jmock. (see http://jira.codehaus.org/browse/JMOCK-194)

If it does not fit to the main goals of jmock i want to publish a seperate project.
Hope that someone can review it in the near future.
In the meantime i try to generalize the control of the injection with something similar to your DSL in your Expections-Class.

You can run the examples with a simple call to "ant" or "ant test" inside the build directory. Before that you should set some pathes in build.properties.
ant test_unwoven shows the results without weaving the mocks.

The test sources are in the path testsrc/incubator/tests.

Hope to hear from you soon.

[Nat Pryce]

Thanks for the contribution.  It doesn't really fit with the core
goals of jMock for two reasons.

1) It adds a dependency on AspectJ.

2) JMock is designed for OOP, not AOP.

So feel free to publish it as a separate project and we'll add a link
to the jMock site.

--Nat


2008/7/9 Sebastian Sickelmann <sebastian.sickelmann@...>:

> HI,
>
> I have created a small extension for injecting jMock at constructor-call.
> I plan to contribute this to jmock, if it fits to the main goals of jmock.
> (see http://jira.codehaus.org/browse/JMOCK-194)
>
> If it does not fit to the main goals of jmock i want to publish a seperate
> project.
> Hope that someone can review it in the near future.
> In the meantime i try to generalize the control of the injection with
> something similar to your DSL in your Expections-Class.
>
> You can run the examples with a simple call to "ant" or "ant test" inside
> the build directory. Before that you should set some pathes in
> build.properties.
> ant test_unwoven shows the results without weaving the mocks.
>
> The test sources are in the path testsrc/incubator/tests.
>
> Hope to hear from you soon.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Sebastian Sickelmann-2]

Thanks for the quick reply.

Just a few things to think of, before we decide "go two seperated ways".

The injection with AspectJ is done in backgound and nobody needs to use
AspectJ in a direct manner.
jmock uses cglib in background too, and so jmock has a dependacy to cglib in
background.
The injection should be done in background behind an OOP(DSL) Interface. At
runtime you need AspectJ for
waeving. Actually i have some problems with LTW(Load-Time-Waeving), so you
have actually manipulate your
build-process for AspectJ, but in future there should be no need for the
user(test-author) to now anything from AOP.
(Just at AspectJ to your classpath of your test-cases and add a simple VMarg
to enable LTW)

If you look at the sourcedirs:
   * src -> behind the scenes. (Part of the framework (jmock or a seperated
extension))
   * testsrc -> thats what the user does. There is no
classpath-dependency(direct or indirect(incubator.MI do not use any AspectJ
related classes) to AspectJ.

DSL lookout:
  // Inject (Mock-)File-Instance when constructorparamater matches new
Object[]{filename}
  final File f = (File) mockery.inject(new ConstructorMatcher() {{
      newInstanceOf(File.class).with(filename); // varargs (so you can use
"ofClass(File.class).with(path,filename)" too)
     }});

// f.isDirectory() -> false
  mockery.checking(new Expectations() {
   {
    one(f).isDirectory();
    will(returnValue(false));
    atLeast(0).of(f).getAbsolutePath();
    will(returnValue(filename));
   }
  });
or
  // Inject (Mock-)File-Instance when constructorparamater matches new
Object[]{filename}
  final File f = (File) mockery.inject(new ConstructorMatcher() {{
      final File mock = newInstanceOf(File.class).with(filename); // varargs
(so you can use "ofClass(File.class).with(path,filename)" too)
      returnMock(new Expectations() {
       {
        one(mock ).isDirectory();
        will(returnValue(false));
        atLeast(0).of(mock).getAbsolutePath();
        will(returnValue(filename));
       }
      });
     }});

But at DSL-Design i am a newbee. There are better ways to do it ;-)

I am also looking to create a new Implementation of
org.jmock.api.Imposteriser that uses AspectJ in background.

Thank you for your efforts in advance. I am looking forward for the result
of your re-review

sincerely yours
Sebastian

----- Original Message -----
From: "Nat Pryce" <nat.pryce@...>
To: <dev@...>
Sent: Wednesday, July 09, 2008 11:01 PM
Subject: Re: [jmock-dev] Contribution to jMock (injection Mocks at
constructor calls)

> Thanks for the contribution.  It doesn't really fit with the core
> goals of jMock for two reasons.
>
> 1) It adds a dependency on AspectJ.
>
> 2) JMock is designed for OOP, not AOP.
>
> So feel free to publish it as a separate project and we'll add a link
> to the jMock site.
>
> --Nat
>
>
> 2008/7/9 Sebastian Sickelmann <sebastian.sickelmann@...>:
>> HI,
>>
>> I have created a small extension for injecting jMock at constructor-call.
>> I plan to contribute this to jmock, if it fits to the main goals of
>> jmock.
>> (see http://jira.codehaus.org/browse/JMOCK-194)
>>
>> If it does not fit to the main goals of jmock i want to publish a
>> seperate
>> project.
>> Hope that someone can review it in the near future.
>> In the meantime i try to generalize the control of the injection with
>> something similar to your DSL in your Expections-Class.
>>
>> You can run the examples with a simple call to "ant" or "ant test" inside
>> the build directory. Before that you should set some pathes in
>> build.properties.
>> ant test_unwoven shows the results without weaving the mocks.
>>
>> The test sources are in the path testsrc/incubator/tests.
>>
>> Hope to hear from you soon.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Sebastian Sickelmann-2]

Hi again,

i have forgotten two thinks:

1. you do not have to ship aspectJ in bin release (because there is no
classpath-dependency). The user can choose his favorit waeving-framework
(actually i have only implemented an AspectJ version on my aspect to weave)
2. Further Enhancement to inject mocks at factorys (ex.
Runtime.getRuntime(), System.loadLibrary(), System.currentTimeMillis()).
These are realy hard to mock if used by the class under test if you do not
want to mangle your code just for testing reason.

Kind regards
Sebastian

----- Original Message -----
From: "Sebastian Sickelmann" <sebastian.sickelmann@...>
To: <dev@...>
Sent: Thursday, July 10, 2008 5:36 AM
Subject: Re: [jmock-dev] Contribution to jMock (injection Mocks at
constructor calls)

> Thanks for the quick reply.
>
> Just a few things to think of, before we decide "go two seperated ways".
>
> The injection with AspectJ is done in backgound and nobody needs to use
> AspectJ in a direct manner.
> jmock uses cglib in background too, and so jmock has a dependacy to cglib
> in background.
> The injection should be done in background behind an OOP(DSL) Interface.
> At runtime you need AspectJ for
> waeving. Actually i have some problems with LTW(Load-Time-Waeving), so you
> have actually manipulate your
> build-process for AspectJ, but in future there should be no need for the
> user(test-author) to now anything from AOP.
> (Just at AspectJ to your classpath of your test-cases and add a simple
> VMarg to enable LTW)
>
> If you look at the sourcedirs:
>   * src -> behind the scenes. (Part of the framework (jmock or a seperated
> extension))
>   * testsrc -> thats what the user does. There is no
> classpath-dependency(direct or indirect(incubator.MI do not use any
> AspectJ related classes) to AspectJ.
>
> DSL lookout:
>  // Inject (Mock-)File-Instance when constructorparamater matches new
> Object[]{filename}
>  final File f = (File) mockery.inject(new ConstructorMatcher() {{
>      newInstanceOf(File.class).with(filename); // varargs (so you can use
> "ofClass(File.class).with(path,filename)" too)
>     }});
>
> // f.isDirectory() -> false
>  mockery.checking(new Expectations() {
>   {
>    one(f).isDirectory();
>    will(returnValue(false));
>    atLeast(0).of(f).getAbsolutePath();
>    will(returnValue(filename));
>   }
>  });
> or
>  // Inject (Mock-)File-Instance when constructorparamater matches new
> Object[]{filename}
>  final File f = (File) mockery.inject(new ConstructorMatcher() {{
>      final File mock = newInstanceOf(File.class).with(filename); //
> varargs (so you can use "ofClass(File.class).with(path,filename)" too)
>      returnMock(new Expectations() {
>       {
>        one(mock ).isDirectory();
>        will(returnValue(false));
>        atLeast(0).of(mock).getAbsolutePath();
>        will(returnValue(filename));
>       }
>      });
>     }});
>
> But at DSL-Design i am a newbee. There are better ways to do it ;-)
>
> I am also looking to create a new Implementation of
> org.jmock.api.Imposteriser that uses AspectJ in background.
>
> Thank you for your efforts in advance. I am looking forward for the result
> of your re-review
>
> sincerely yours
> Sebastian
>
> ----- Original Message -----
> From: "Nat Pryce" <nat.pryce@...>
> To: <dev@...>
> Sent: Wednesday, July 09, 2008 11:01 PM
> Subject: Re: [jmock-dev] Contribution to jMock (injection Mocks at
> constructor calls)
>
>
>> Thanks for the contribution.  It doesn't really fit with the core
>> goals of jMock for two reasons.
>>
>> 1) It adds a dependency on AspectJ.
>>
>> 2) JMock is designed for OOP, not AOP.
>>
>> So feel free to publish it as a separate project and we'll add a link
>> to the jMock site.
>>
>> --Nat
>>
>>
>> 2008/7/9 Sebastian Sickelmann <sebastian.sickelmann@...>:
>>> HI,
>>>
>>> I have created a small extension for injecting jMock at
>>> constructor-call.
>>> I plan to contribute this to jmock, if it fits to the main goals of
>>> jmock.
>>> (see http://jira.codehaus.org/browse/JMOCK-194)
>>>
>>> If it does not fit to the main goals of jmock i want to publish a
>>> seperate
>>> project.
>>> Hope that someone can review it in the near future.
>>> In the meantime i try to generalize the control of the injection with
>>> something similar to your DSL in your Expections-Class.
>>>
>>> You can run the examples with a simple call to "ant" or "ant test"
>>> inside
>>> the build directory. Before that you should set some pathes in
>>> build.properties.
>>> ant test_unwoven shows the results without weaving the mocks.
>>>
>>> The test sources are in the path testsrc/incubator/tests.
>>>
>>> Hope to hear from you soon.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2008/7/10 Sebastian Sickelmann <sebastian.sickelmann@...>:
> Actually i have some problems with LTW(Load-Time-Waeving), so you
> have actually manipulate your
> build-process for AspectJ,

This would not be acceptable for code in the main jMock distribution.

> but in future there should be no need for the
> user(test-author) to now anything from AOP.
> ...
> But at DSL-Design i am a newbee. There are better ways to do it ;-)

If the API is in flux, it cannot go in the core.  In my experience it
takes a long time to develop an API that balances flexibility and
readability.  It needs to be used in practice by a number of people
and that experience fed back into the design.

Your code sounds too immature to go into the main distribution.  You
should start your own project and get people to use it, to stabilise
the API.  I'd be happy to add a link to the jMock page.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2008/7/10 Sebastian Sickelmann <sebastian.sickelmann@...>:
> 2. Further Enhancement to inject mocks at factorys (ex.
> Runtime.getRuntime(), System.loadLibrary(), System.currentTimeMillis()).
> These are realy hard to mock if used by the class under test if you do not
> want to mangle your code just for testing reason.

One of JMock's goals is to make the testing process highlight where
you need to improve your design.  E.g. static calls to system services
makes code hard to test and hard to evolve over time. It sounds as if
your project is not directly aligned with those goals and so would be
better as a separate project.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email