JUnit 4 support without extending MockObjectTestCase

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1.0
  • Fix Version/s: 2.0.0
  • Component/s: JMock 2.x.x Library
  • Labels:
    None
  • Testcase included:
    yes

Description

I wrote a code to support JUnit 4 without making the test class inherit from MockObjectTestCase.
I attached the code with tests.
Please verify if this approach is feasible.

There are three main features:

1. Separated the mock creation from the MockObjectTestCase hierarchy.
This is achieved by creating new classes (org.jmock.junit4.MockManager and org.jmock.cglib.junit4.MockManager in my source code).
Usage:
MockManager mockManager;
Mock mock;
@Before public void setUp( ) { mockManager = new MockManager( ); mock = mockManager.mock( .. ); }

2. Separated the verification from the VerifyingTestCase hierarchy.
A new class (org.jmock.junit4.VerificationManager in my source code) is created. The MockManager class above has a delegated verify method to delegate verification to VerificationManager.
Usage:
@After public void tearDown( ) { mockManager.verify( ); }

3. The mock supports methods (e.g. eq(..) ) are statically imported (just like assert.. methods).
Separated the mock support methods e.g. eq(..) from TestCase hierachy.
A new class (org.jmock.junit4.MockSupporter in my source code) with static methods is created.
Usage (same as before other than the static import):
import static org.jmock.junit4.MockSupporter.*;
...
mock.expects( once( ) ).method( "methodName" ).with( eq( .. ) ).will( returnValue( .. ) );

Two test classes (one for mocking interface and the other for class with CGLIB) to test those features describe how to use them. By the way, I used JUnit 4 format for those test classes.

Also just as an idea, I modified the existing MockObjectTestCase, MockObjectSupportTestCase, and VerifyingTestCase to delegate their functionalities to the corresponding Managers above, so that they can be still used as they have been used without the code duplication. In my source code, I put them under org.jmock.oldJUnit and org.jmock.cglib.oldJUnit because I didn't want to change the existing code because this is just an idea.

The attached code follows the default Maven structure, i.e. the source codes are under src/main/java and the test codes are under src/test/java because I am not able to access CVS so I don't know what test directory structure jMock has...

If this approach is feasible, please give me an anonymous cvs read access so that I can run the existing tests there with this code.

Thank you.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tadatoshi Takahashi added a comment -

P.S.

The code is based on 1.1.0-RC1 and JUnit 4.1.

Show
Tadatoshi Takahashi added a comment - P.S. The code is based on 1.1.0-RC1 and JUnit 4.1.
Hide
Permalink
David Billskog added a comment -

This improvement is great! It has been very helpful in my project, thank you.

The only thing I doesn't like is the Constraint constants (ANYTHING, NULL, NOT_NULL) in MockSupporter that is in my opinion disrupting the flow of the syntax. I would suggest replacing those constants with:

public static Constraint isNull() {
return new IsNull();
}

public static Constraint notNull() {
return new IsNot(new IsNull());
}

public static Constraint anything() {
return new IsAnything();
}

Show
David Billskog added a comment - This improvement is great! It has been very helpful in my project, thank you. The only thing I doesn't like is the Constraint constants (ANYTHING, NULL, NOT_NULL) in MockSupporter that is in my opinion disrupting the flow of the syntax. I would suggest replacing those constants with: public static Constraint isNull() { return new IsNull(); } public static Constraint notNull() { return new IsNot(new IsNull()); } public static Constraint anything() { return new IsAnything(); }
Hide
Permalink
Tadatoshi Takahashi added a comment -

Thank you for your comment.

I am glad that this improvement is helping your project.

About the Constraint constants, I think it is a separate issue.
So maybe you can create another issue about it.

For example, currently we can write the code like this:
mock.expects( once( ) ).method( "someMethod" ).with( NOT_NULL );
if you want to only check if the passed argument to the method is not null.
Or
mock.expects( once( ) ).method( "someMethod" ).with( eq( someSpecificValue ), ANYTHING );
if you want to only check that the first argument has some specific value.

I think it's better to create another issue and ask all the users if they agree to use notNull( ) and anything( ) instead in the cases above.

Show
Tadatoshi Takahashi added a comment - Thank you for your comment. I am glad that this improvement is helping your project. About the Constraint constants, I think it is a separate issue. So maybe you can create another issue about it. For example, currently we can write the code like this: mock.expects( once( ) ).method( "someMethod" ).with( NOT_NULL ); if you want to only check if the passed argument to the method is not null. Or mock.expects( once( ) ).method( "someMethod" ).with( eq( someSpecificValue ), ANYTHING ); if you want to only check that the first argument has some specific value. I think it's better to create another issue and ask all the users if they agree to use notNull( ) and anything( ) instead in the cases above.
Hide
Permalink
Tadatoshi Takahashi added a comment -

I attached the jar file so that this improvement can be tried out immediately.

Show
Tadatoshi Takahashi added a comment - I attached the jar file so that this improvement can be tried out immediately.
Hide
Permalink
Tadatoshi Takahashi added a comment -

I also attached the Maven POM file for the jar file for the users who use Maven to manage libraries.

Show
Tadatoshi Takahashi added a comment - I also attached the Maven POM file for the jar file for the users who use Maven to manage libraries.
Hide
Permalink
Tadatoshi Takahashi added a comment -

About the David Billskog's comment, the Issue JMock-101 seems to be related.
Maybe David's comment can be added to the Issue JMock-101.

Show
Tadatoshi Takahashi added a comment - About the David Billskog's comment, the Issue JMock-101 seems to be related. Maybe David's comment can be added to the Issue JMock-101.
Hide
Permalink
M.H. Avegaart added a comment -

The MockSupporter class can also be used by people (like me) who don't use JUnit4, but want to inherit from a different TestCase descendant and still be able to use the MockObjectSupportTestCase methods.
This however could also be solved by making all methods in MockObjectSupportTestCase static.

ps.
Reply to David Billskog:
I also agree that methods look better than constants, but the implementation should be:

private static final Constraint ANYTHING = new IsAnything();
private static final Constraint NULL = new IsNull();
private static final Constraint NOT_NULL = new IsNot(NULL);

public static Constraint anything() { return ANYTHING; }
public static Constraint isNull() { return NULL; }
public static Constraint notNull() { return NOT_NULL; }

Show
M.H. Avegaart added a comment - The MockSupporter class can also be used by people (like me) who don't use JUnit4, but want to inherit from a different TestCase descendant and still be able to use the MockObjectSupportTestCase methods. This however could also be solved by making all methods in MockObjectSupportTestCase static. ps. Reply to David Billskog: I also agree that methods look better than constants, but the implementation should be: private static final Constraint ANYTHING = new IsAnything(); private static final Constraint NULL = new IsNull(); private static final Constraint NOT_NULL = new IsNot(NULL); public static Constraint anything() { return ANYTHING; } public static Constraint isNull() { return NULL; } public static Constraint notNull() { return NOT_NULL; }
Hide
Permalink
Tadatoshi Takahashi added a comment -

Thank you for your comment.

It's a good point that sometimes there is a case when you want your Test class inherit from a different TestCase subclass when using pre-JUnit4. I am glad that the MockSupporter class can be helpful for pre-JUnit4 unexpectedly.

Show
Tadatoshi Takahashi added a comment - Thank you for your comment. It's a good point that sometimes there is a case when you want your Test class inherit from a different TestCase subclass when using pre-JUnit4. I am glad that the MockSupporter class can be helpful for pre-JUnit4 unexpectedly.
Hide
Permalink
Tadatoshi Takahashi added a comment -

Just FYI.
Eclipse 3.2 supports JUnit4.
But when using jMock without this improvement, (i.e. by extending MockObjectTestCase), Eclipse treats the test class as JUnit3.8 test and @Test annotation is ignored. If you don't prefix test methods with "test", Eclipse displays error message saying that no test methods are found.
(I do Test-Driven Development and name test methods to describe the bahavior. So I don't prefix the test methods with "test" any more after I started using JUnit4.)
So I think we should make jMock support JUnit4 without making test class extend MockObjectTestCase.

Show
Tadatoshi Takahashi added a comment - Just FYI. Eclipse 3.2 supports JUnit4. But when using jMock without this improvement, (i.e. by extending MockObjectTestCase), Eclipse treats the test class as JUnit3.8 test and @Test annotation is ignored. If you don't prefix test methods with "test", Eclipse displays error message saying that no test methods are found. (I do Test-Driven Development and name test methods to describe the bahavior. So I don't prefix the test methods with "test" any more after I started using JUnit4.) So I think we should make jMock support JUnit4 without making test class extend MockObjectTestCase.
Hide
Permalink
Nat Pryce added a comment -

jMock 2 is designed to be independent of any test framework. It has well defined plugin points through which it can be integrated with JUnit 3, JUnit 4, TestNG, etc.

Show
Nat Pryce added a comment - jMock 2 is designed to be independent of any test framework. It has well defined plugin points through which it can be integrated with JUnit 3, JUnit 4, TestNG, etc.

People

  • Assignee:
    Nat Pryce
    Reporter:
    Tadatoshi Takahashi
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: