Version 2.5.0-RC1 Released

[Nat Pryce]

Hi all.  I've just published a new 2.5.0-RC1 version.

Release notes are at:
  http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=13840

We've changed the way that jMock works under the hood. The Mockery is
no longer modal.  Evaluating an expectations block does not switch the
mockery into "capture" mode and then back to "testing" mode.  The
mockery is always in "testing" mode, and mocks create capturing
imposters inside expectation blocks.

As I said, that's all under the hood.  The API is exactly the same,
and you should not see any difference in your tests.  If you do,
please shout!

--Nat

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

    http://xircles.codehaus.org/manage_email

[Geoffrey Wiseman]

On Wed, Jun 25, 2008 at 8:29 AM, Nat Pryce <nat.pryce@...> wrote:

We've changed the way that jMock works under the hood. The Mockery is
no longer modal.  Evaluating an expectations block does not switch the
mockery into "capture" mode and then back to "testing" mode.  The
mockery is always in "testing" mode, and mocks create capturing
imposters inside expectation blocks.

So, short of the desire to be on the current release, is there any reason to upgrade?

I could see if if I were tinkering with the internals and I wanted to 'catch up', but that's not true.  Just checking if there's any other reason that wasn't apparent from the above.

  - Geoffrey
--
Geoffrey Wiseman

[Nat Pryce]

I should have been more clear: there's much more in the release than
the internal tinkering. The changelog in JIRA that was linked in the
email I sent describes the new features, improvements and bug fixes
that are in the new release.

We tinkering was necessary to address issues reported by users via
JIRA.  Because it's quite a significant change in implementation, it
would be helpful if existing users tried the release candidate in
their projects and let us know if it worked or not.

Cheers,

--Nat.

2008/6/25 Geoffrey Wiseman <geoffrey.wiseman@...>:

> On Wed, Jun 25, 2008 at 8:29 AM, Nat Pryce <nat.pryce@...> wrote:
>>
>> We've changed the way that jMock works under the hood. The Mockery is
>> no longer modal.  Evaluating an expectations block does not switch the
>> mockery into "capture" mode and then back to "testing" mode.  The
>> mockery is always in "testing" mode, and mocks create capturing
>> imposters inside expectation blocks.
>
> So, short of the desire to be on the current release, is there any reason to
> upgrade?
>
> I could see if if I were tinkering with the internals and I wanted to 'catch
> up', but that's not true.  Just checking if there's any other reason that
> wasn't apparent from the above.
>
>   - Geoffrey
> --
> Geoffrey Wiseman
>

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

    http://xircles.codehaus.org/manage_email

[Geoffrey Wiseman]

On Wed, Jun 25, 2008 at 3:05 PM, Nat Pryce <nat.pryce@...> wrote:

I should have been more clear: there's much more in the release than
the internal tinkering. The changelog in JIRA that was linked in the
email I sent describes the new features, improvements and bug fixes
that are in the new release.

Ah, sorry -- I should have read the attached link before asking.  ;)

  - Geoffrey

--
Geoffrey Wiseman

[Dale King-2]

On Wed, Jun 25, 2008 at 2:24 PM, Geoffrey Wiseman
<geoffrey.wiseman@...> wrote:
>
> I could see if if I were tinkering with the internals and I wanted to 'catch
> up', but that's not true.  Just checking if there's any other reason that
> wasn't apparent from the above.

Coming from someone who has tried to tinker with the internals a bit I
can tell you that it really isn't possible to tinker with the
internals of JMock. The ONLY place that extension is possible is by
providing a different Imposteriser, which isn't much.

For anything else you essentially have to make a copy of the existing
code and change the copy since the internals are completely locked
down.

--
Dale King

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

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2008/6/27 Dale King <dalewking@...>:
> Coming from someone who has tried to tinker with the internals a bit I
> can tell you that it really isn't possible to tinker with the
> internals of JMock. The ONLY place that extension is possible is by
> providing a different Imposteriser, which isn't much.

You can also plug in new matchers, actions, naming conventions and
exception translators.  And you can use matchers to match invoked
objects and invoked methods, as well as parameters.

--Nat

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

    http://xircles.codehaus.org/manage_email

[Dale King-2]

On Wed, Jun 25, 2008 at 8:29 AM, Nat Pryce <nat.pryce@...> wrote:

> Hi all.  I've just published a new 2.5.0-RC1 version.
>
> Release notes are at:
>  http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=13840
>
> We've changed the way that jMock works under the hood. The Mockery is
> no longer modal.  Evaluating an expectations block does not switch the
> mockery into "capture" mode and then back to "testing" mode.  The
> mockery is always in "testing" mode, and mocks create capturing
> imposters inside expectation blocks.
>
> As I said, that's all under the hood.  The API is exactly the same,
> and you should not see any difference in your tests.  If you do,
> please shout!

Do you recall my messages from almost a year ago about my Imposteriser
for JNI native methods that allows you to mock native method calls. In
order to allow  you to specify expectations for native methods using
the normal Jmock method of calling the actual methods instead of using
the JMock 1 style of expectations I had to make my own copies of
Expectations and InvocationExpectationBuilder and tweak them.

Well I just wanted to let you know that this change completely blows
that out of the water. To do it now would require copying more
classes. The issue is that your method now relies on creating a
different instance to return from the cardinality clauses and it is
the fact that you are invoking on this different instance that
specifies that this is an expectation. As I explained earlier for
mocking native methods there is no instance that the Imposteriser is
generating (it in fact returns null) so I can't return a different
instance. The instance for a native method is an existing instance or
in the case of static native methods the class. The change I had made
before was to tweak InvocationExpectationBuilder to allow an alternate
means of going from the "instance" that the method was invoked on to a
CaptureControl other than the assumption that they are one and the
same instance.

This is not meant as a complaint, merely an FYI. In the end it doesn't
matter much. You will just have to use the JMock 1 style of
expectation specification for my native Imposteriser and that requires
no changes to JMock. The ability to specify native mocks via
invocation is not that important any way because in order to do so the
native methods would have to be accessible and in any good design they
would be private.

--
Dale King

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

    http://xircles.codehaus.org/manage_email

[Dale King-2]

On Fri, Jun 27, 2008 at 10:09 AM, Nat Pryce <nat.pryce@...> wrote:
> 2008/6/27 Dale King <dalewking@...>:
>> Coming from someone who has tried to tinker with the internals a bit I
>> can tell you that it really isn't possible to tinker with the
>> internals of JMock. The ONLY place that extension is possible is by
>> providing a different Imposteriser, which isn't much.
>
> You can also plug in new matchers, actions, naming conventions and
> exception translators.  And you can use matchers to match invoked
> objects and invoked methods, as well as parameters.

Sorry, I was referring to the "internals" which is a rather vague
term. My first sentence is correct, but you are correct that the
second sentence needed a lot more qualification.

My point was that the internals are very locked down and cannot be
extended without actually duplicating huge swaths of code. I know that
is by design.

--
Dale King

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

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

I do remember and I believe I warned you that you were using jMock in
a way that it was not designed to support and, furthermore, that it
was designed not to support.

I'm sorry your code broke, but we divided the code into public plugin
points and internal implementation details to be clear about what can
and cannot be relied upon, changewise.

On the subject of mocking native methods, in the past I've defined an
interface for the native code, implemented it with JNI and mocked the
interface with jMock.  That approach worked pretty well and didn't
need any tricks to mock static methods or mock only parts of an
object.

--Nat

2008/6/27 Dale King <dalewking@...>:

> On Wed, Jun 25, 2008 at 8:29 AM, Nat Pryce <nat.pryce@...> wrote:
>> Hi all.  I've just published a new 2.5.0-RC1 version.
>>
>> Release notes are at:
>>  http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=13840
>>
>> We've changed the way that jMock works under the hood. The Mockery is
>> no longer modal.  Evaluating an expectations block does not switch the
>> mockery into "capture" mode and then back to "testing" mode.  The
>> mockery is always in "testing" mode, and mocks create capturing
>> imposters inside expectation blocks.
>>
>> As I said, that's all under the hood.  The API is exactly the same,
>> and you should not see any difference in your tests.  If you do,
>> please shout!
>
> Do you recall my messages from almost a year ago about my Imposteriser
> for JNI native methods that allows you to mock native method calls. In
> order to allow  you to specify expectations for native methods using
> the normal Jmock method of calling the actual methods instead of using
> the JMock 1 style of expectations I had to make my own copies of
> Expectations and InvocationExpectationBuilder and tweak them.
>
> Well I just wanted to let you know that this change completely blows
> that out of the water. To do it now would require copying more
> classes. The issue is that your method now relies on creating a
> different instance to return from the cardinality clauses and it is
> the fact that you are invoking on this different instance that
> specifies that this is an expectation. As I explained earlier for
> mocking native methods there is no instance that the Imposteriser is
> generating (it in fact returns null) so I can't return a different
> instance. The instance for a native method is an existing instance or
> in the case of static native methods the class. The change I had made
> before was to tweak InvocationExpectationBuilder to allow an alternate
> means of going from the "instance" that the method was invoked on to a
> CaptureControl other than the assumption that they are one and the
> same instance.
>
> This is not meant as a complaint, merely an FYI. In the end it doesn't
> matter much. You will just have to use the JMock 1 style of
> expectation specification for my native Imposteriser and that requires
> no changes to JMock. The ability to specify native mocks via
> invocation is not that important any way because in order to do so the
> native methods would have to be accessible and in any good design they
> would be private.
>
> --
> Dale King
>
> ---------------------------------------------------------------------
> 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