headers
Duncan Jones | 21 Feb 2013 14:06
Gravatar

Unexpected behaviour with package private classes - IllegalAccessError

Hi,

I've encountered some strange behaviour when using package private
classes within expectations. The proxy class gets an
IllegalAccessError when referring to a package private class instance
in a return value.

I've attached a minimal working Maven project ("example-project.zip"),
which demonstrates the behaviour. I'm unclear whether this is expected
or not.

Some notes:

 - The issue does not occur if the method in question returns null
(see testSuccess() in my example test file).

 - If I convert ExampleInterface to be package private, the error does
not occur.

Kind regards,

Duncan
Attachment (example-project.zip): application/zip, 3156 bytes

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

    http://xircles.codehaus.org/manage_email
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Freeman | 7 Jan 2013 15:33
Picon

jmock maven distribution?

Where are we with this?

S.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Steve Freeman | 30 Dec 2012 23:23
Picon

doesn't compile with Java 7. Breaking change?

It turns out that JMock doesn't compile with Java7. They've changed the type system so that it doesn't know
what to do with all the overloads of the with() method in ArgumentConstraintPhrases. If we delete the
overloads for the primitive types to make the code compile, then it fails at runtime because we cannot
return null as a primitive type and we don't have a runtime way to find out what type we're supposed to be
returning. 

The best we can think of is to do something based on Expectations.WithClause where we specify the return
type in the method name for primitives, for example:

  oneOf(foo).blah(with.intIs(lessThan(2)));

Unfortunately, this is a breaking change.

Unless someone has a better idea, we'll do this in the next release (2.7). This new API should still compile
and work with Java 6, even if it's more clunky.

Thoughts?

S.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 3 comments |
headers
Steve Freeman (JIRA | 20 Dec 2012 10:37

[jira] (JMOCK-172) Make it easy to define a block of expectations that only occur in a given state

Steve Freeman closed JMOCK-172 as Won't Fix
Change By: Steve Freeman (20/Dec/12 3:35 AM)
Resolution: Won't Fix
Assignee: Steve Freeman
Status: Open Closed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Steve Freeman (JIRA | 20 Dec 2012 10:35

[jira] (JMOCK-163) Add action to save the parameters in the call

Steve Freeman closed JMOCK-163 as Won't Fix
Change By: Steve Freeman (20/Dec/12 3:35 AM)
Resolution: Won't Fix
Assignee: Steve Freeman
Status: Open Closed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Steve Freeman (JIRA | 20 Dec 2012 10:25

[jira] (JMOCK-185) new will() methods for terse referring to parameters.

Steve Freeman closed JMOCK-185 as Fixed
Change By: Steve Freeman (20/Dec/12 3:24 AM)
Resolution: Fixed
Assignee: Steve Freeman
Status: Open Closed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Duncan McGregor (JIRA | 15 Dec 2012 11:47

[jira] (JMOCK-269) MethodMatcher can fail for restatement of generic method
Issue Type: Bug
Affects Versions: 2.6.0
Assignee: Unassigned
Components: JMock 2.x.x Library
Created: 15/Dec/12 4:46 AM
Description:

import org.jmock.Expectations;
import org.jmock.integration.junit4.JUnitRuleMockery;
import org.junit.Rule;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class JMockMethodMatchingTest
{
<at> Rule public JUnitRuleMockery context = new JUnitRuleMockery();

private static interface Function<F, T> { T apply(F input); }

private static interface StringFunction extends Function<String, String> { <at> Override public String apply(String input); }

private Function<String, String> mockedFunction = context.mock(Function.class);
private StringFunction mockedStringFunction = context.mock(StringFunction.class);

<at> Test
public void test() throws Exception
{
context.checking(new Expectations() {{
allowing (mockedStringFunction).apply("alice");
will (returnValue("bob"));
allowing (mockedFunction).apply("alice");
will (returnValue("bob"));
}});

assertEquals("bob", mockedFunction.apply("alice"));
assertEquals("bob", mockedStringFunction.apply("alice"));

assertEquals("bob", apply(mockedFunction, "alice"));
assertEquals("bob", apply(mockedStringFunction, "alice"));
// java.lang.AssertionError: unexpected invocation: stringFunctor.apply("alice")
}

private String apply(Function<String, String> f, String arg) { return f.apply(arg); }
}
Project: jMock
Priority: Major
Reporter: Duncan McGregor
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Andreas Brieg (JIRA | 6 Nov 2012 09:27

[jira] (JMOCK-268) Improve support for specifying expectations on a Matcher
Issue Type: Bug
Affects Versions: 2.5.1
Assignee: Unassigned
Components: JMock 2.x.x Library
Created: 06/Nov/12 2:26 AM
Description:

I want to test a class, that internally uses a hamcrest Matcher. I mock that Matcher and want to specify expectations on it. So normally I would write:

allowing(matcher).describeTo(with(any(Description.class)));

But this gives a compile error, because the overload of allowing that takes a Matcher as an argument is chosen. But this overload returns a MethodClause instead of the mocked Matcher. So I need to write

((Matcher<?>) allowing((Object) matcher)).describeTo(with(any(Description.class))); {java} to invoke the correct overload. This looks quite ugly, because the intent of the casts isn't clear on the first look. Could we provide a method in {{org.jmock.syntax.ReceiverClause}} that receives a Matcher but handles this as a mock object and delegates to {{org.jmock.syntax.ReceiverClause.of(T)}}. The method could for example look like {code:java} <T> T ofMock(T mock);

There is no need to to specialize that method on matchers. But either it should be documented that this method is intended to be used for specifying expectations on a Matcher or it should be specialized on Matchers.
This solution doesn't explicitly solve the problem with allowing mentioned above. But providing a new method for everything in org.jmock.syntax.CardinalityClause that takes a mock object just doesn't seem worth the effort. So I would be lucky if I could write

atLeast(0).ofMock(matcher).describeTo(with(any(Description.class)));
Project: jMock
Priority: Minor
Reporter: Andreas Brieg
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 6 comments |
headers
Steve Freeman | 22 Oct 2012 10:29
Picon

jmock.org

I'm in the process of moving the domain to our new repo at github.

Let me know if there are any problems.

Ta

S.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 4 comments |
headers
Sebastian Carneiro (JIRA | 26 Sep 2012 05:05

[jira] (JMOCK-267) jMock fails to build from source with openjdk-7
Issue Type: Bug
Affects Versions: 2.5.1
Assignee: Unassigned
Attachments: jmock2_2.5.1+dfsg-1-i386-20120925-2045
Components: JMock 2.x.x Library
Created: 25/Sep/12 10:05 PM
Description:

jMock2 fails to build from source in Ubuntu 12.10, with OpenJDK 7. Ubuntu bug is:

Attached is the build log from Ubuntu.
Environment: Ubuntu 12.10 Quantal Quetzal - OpenJDK 7
Project: jMock
Priority: Major
Reporter: Sebastian Carneiro
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Duncan Jones (JIRA | 21 Sep 2012 12:42

[jira] (JMOCK-266) jmock-junit4 2.6.0-RC2 POM refers to wrong junit:junit-dep version
Issue Type: Bug
Assignee: Unassigned
Components: Maven Packaging
Created: 21/Sep/12 5:41 AM
Description:

The POM for jmock-junit4 2.6.0-RC2 refers to v4.4 of junit-dep:

<dependency> <groupId>junit</groupId> <artifactId>junit-dep</artifactId> <version>4.4</version> <exclusions> <exclusion> <!-- Excluded as already a transitive dep of jmock --> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-core</artifactId> </exclusion> </exclusions> </dependency>

This will not work, as junit-dep does not contain org.junit.runners.BlockJUnit4ClassRunner which is required by org.jmock.integration.junit4.JMock. The required class first appears in junit-dep 4.5.

A work-around is to specifically exclude this dependency when using JMock:

<!-- JMock --> <dependency> <groupId>org.jmock</groupId> <artifactId>jmock</artifactId> <version>2.6.0-RC2</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jmock</groupId> <artifactId>jmock-junit4</artifactId> <version>2.6.0-RC2</version> <scope>test</scope> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit-dep</artifactId> </exclusion> </exclusions> </dependency> <!-- End JMock -->
Project: jMock
Priority: Major
Reporter: Duncan Jones
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Permalink | Reply | 6 comments |

Gmane