jMock

An ability to use annotation to create mock objects

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.5.0
  • Fix Version/s: 2.6.0
  • Component/s: JMock 2.x.x Library
  • Labels:
    None
  • Number of attachments :
    2

Description

Hi,

it could be very nice to have an ability to mark fields in test case to be mocked.

For example, any field in test case marked with annotation @Mocked will be assigned a value.

Actually, I have implemented such feature for Jmock 2.5.0 & Junit 4.4 and I'll include sample code.

Attachments

  1. Java Source File
    JMockRunner.java
    23/Apr/09 8:31 AM
    3 kB
    Ignat Zapolsky
  2. Java Source File
    Mocked.java
    23/Apr/09 8:31 AM
    0.4 kB
    Ignat Zapolsky

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ignat Zapolsky added a comment -

Annotation source code, Runner source code.

Show
Ignat Zapolsky added a comment - Annotation source code, Runner source code.
Hide
Permalink
Steve Freeman added a comment -

it's true that we trigger a certain amount of repetitive code which mockito, for one, avoids with annotations.

My problem with this suggestion is that for it to work I'd have to turn off the compiler warning about using uninitialised values. I've developed a habit of making as many fields final as possible to reduce mutability.

Show
Steve Freeman added a comment - it's true that we trigger a certain amount of repetitive code which mockito, for one, avoids with annotations. My problem with this suggestion is that for it to work I'd have to turn off the compiler warning about using uninitialised values. I've developed a habit of making as many fields final as possible to reduce mutability.
Hide
Permalink
Ignat Zapolsky added a comment -

I'd rather use annotation that could force compiler to emit extra code, since mock object type is available from declaration type. This change could require more efforts than runtime version (which is mostly straightforward).

Unfortunately there is no well-defined @SuppresWarnings annotation value to get rid of "usage of uninitialized variable".

Show
Ignat Zapolsky added a comment - I'd rather use annotation that could force compiler to emit extra code, since mock object type is available from declaration type. This change could require more efforts than runtime version (which is mostly straightforward). Unfortunately there is no well-defined @SuppresWarnings annotation value to get rid of "usage of uninitialized variable".
Hide
Permalink
Nat Pryce added a comment -

I like this suggestion. Code that creates named mock objects is repetitive and this could solve that. I've run the idea past a few people and they all like it.

My one reservation is that test setup is no longer explicit. I think implementing this as a subclass of the JMock test-runner is a good idea, maybe named JMockMagic or something similar to warn the reader that magic set-up is happening.

Unused variable warnings can be avoided by making the variables package-protected. I usually don't bother to make fields private in test classes anyway. I do like them to be final, but there may be some reflection workaround for that.

The code submitted is not acceptable as it stands. It will fail if there are two mock objects of the same type, for example, does not name the mock objects after the field names, and is written to an old version of JUnit 4.

However, we'll implement something like this in a forthcoming JMock version.

Show
Nat Pryce added a comment - I like this suggestion. Code that creates named mock objects is repetitive and this could solve that. I've run the idea past a few people and they all like it. My one reservation is that test setup is no longer explicit. I think implementing this as a subclass of the JMock test-runner is a good idea, maybe named JMockMagic or something similar to warn the reader that magic set-up is happening. Unused variable warnings can be avoided by making the variables package-protected. I usually don't bother to make fields private in test classes anyway. I do like them to be final, but there may be some reflection workaround for that. The code submitted is not acceptable as it stands. It will fail if there are two mock objects of the same type, for example, does not name the mock objects after the field names, and is written to an old version of JUnit 4. However, we'll implement something like this in a forthcoming JMock version.
Hide
Permalink
Steve Freeman added a comment -

I think there's a good case to be made for an alternative lighter-weight API in general.
We can do this as an extension and people can use the version they like.

Show
Steve Freeman added a comment - I think there's a good case to be made for an alternative lighter-weight API in general. We can do this as an extension and people can use the version they like.
Hide
Permalink
Nat Pryce added a comment -

implementation checked in to SVN

Show
Nat Pryce added a comment - implementation checked in to SVN

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.