jmock 2.6 compatibility with Java 7

Hi,

Is jmock 2.6 compatible with java 7 ?

Thanks,
Prasanna

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

    http://xircles.codehaus.org/manage_email

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

jmock.org, now including javadoc

so, I had to hide away in the mountains, but I believe I've finally managed to get the javadoc working for
released builds on http://www.jmock.org

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

    http://xircles.codehaus.org/manage_email

Due date for 2.6.0 (revisited)

I'm aware this has been asked before, but it's been quite a while ago in
January 2012: is there a planned due date for 2.6.0?

Just like Julian in the January post, we do not have the need for any
particular features, but we are concerned about the propects of the JMock
library. Issues are answered, but no visible progress on the code has been
made since 2.6.0-RC2 was published, and there is no due date for 2.6.0
final.

We have written a large number of tests using JMock in the past years and
would love to continue doing so. However the development team have been
pointing out the perceived lack of activity and are starting to ponder
moving to another library despite the fragmented setup this would create for
us.

Is there anything worth knowing that would convince our team otherwise?

Kind regards
  Tobias
--

-- 
View this message in context: http://old.nabble.com/Due-date-for-2.6.0-%28revisited%29-tp34696225p34696225.html
Sent from the jMock - User mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

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

Mock a interface and get values from a implementation.

Hello Guys,

I have this question and I have been trying to get a solution for long
time now but I'm still unanswered.

I want to mock an interface and create expectations just for some methods
but all other methods, to return values from the implementation.

For example, say this interface:

public interface Calculator {
    public double sum(double a, double b, double c);
    public double multiply(double a, double b, double c);
    public double substract(double a, double b, double c);
    public double divide(double a, double b, double c);
}

Then I want to mock only the sum method so I create:

context.checking(new Expectations() {{
    oneOf(calculator).sum(3,4,5);
    will(returnValue((3*3*5.0)));
}});

and the test:

double result = calculator.sum(3,4,5);
assertEquals(3*3*5.0, result);

double resultd = calculator.multiply(3,4,5);

How to check object state inside a mock call

Hi,

I am trying to develop a class performing callbacks using JMock. 
I have to check some properties of the calling object of the tested class RuleEngine during the callback. 
After the call finishes its state is lost. 

So I wrote the following:

 <at> RunWith(JMock.class)
public class RuleEngineTest {
 Mockery context = new JUnit4Mockery();
 Code code = context.mock(Code.class);
  <at> Test
 public void emptyRuleSetRunsCodeOnce() {
 final RuleEngine ruleEngine = new RuleEngine();
 context.checking(new Expectations() {{
 oneOf(code).run();
 will(new CheckingAction(){
  <at> Override
 protected void doChecks() {
 // Do some state checks of ruleEngine object
 }});
 }});

 ruleEngine.run(code);
 }
}

public abstract class CheckingAction extends ReturnDefaultValueAction{

Unsatisfied expections

ignoring except never for one method

I want to ignore all calls on an object but not allow one particular call

eg Ithought this should work, but it allows the kill method to be called too

 never(conversation).kill(with(any(String.class)));
 ignoring(conversation);

I don't want to have to specify every call on conversation - that makes the
test brittle as the class is tweaked/refactored
--

-- 
View this message in context: http://old.nabble.com/ignoring-except-never-for-one-method-tp34047514p34047514.html
Sent from the jMock - User mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

Re: JMock map expectations

Thank you for the reply,

After you said it's not possible to make it nice, I thought about it a
bit and would like to propose a couple of alternative solutions. It's
going to be wordy, but I coudn't leave anything out - java generics is
not an easy stuff.

So, the inital idea of JMock was to use existing hamcrest matchers for
specifying expectations by wrapping them in with(). But a problem
arises with "generic" matchers (I didn't mean java generics here, I
meant matchers for base types and matchers with wildcards), like:
public static <K, V> Matcher<Map<? extends K, ? extends V>> hasEntry(K
param1, V param2)
public static <T> Matcher<java.lang.Iterable<? extends T>>
containsInAnyOrder(T... param1)

if we use these matchers in expectations like:
            oneOf(service).doSomethingWithAMap(with(hasEntry("test", "test")));
            oneOf(service).doSomethingWithAList(with(containsInAnyOrder("test")));

the code won't compile, because with() inferred types as:
Map<? extends String,? extends String>
Iterable<? extends String>

which our service does not accept. It wants something more specific:
public interface Service {
    void doSomethingWithAMap(Map<String, String> map);
    void doSomethingWithAList(List<String> list);
}

The problem is that methods hasEntry() and containsInAnyOrder() infer
container parameters, but specify container types explicitly.
So even if we try to use java "infer from assignment" feature:
            Matcher<Map<String, String>> mapMatcher = hasEntry("test", "test");
            oneOf(service).doSomethingWithAMap(with(mapMatcher));
it won't compile, since hasEntry() returns Map<? extends String,?
extends String>.

But we can add another level of indirection to infer actual map type,
so we could pass it to doSomethingWithAMap() method.

Consider this method:
    public <T> Matcher<T> wrap(Matcher<? super T> matcher) {
        return new LooseMatcherWrapper<T>(matcher);
    }

where LooseMatcherWrapper simply delegates all calls to the
constructor parameter.

public class LooseMatcherWrapper<T> extends BaseMatcher<T> {
    private Matcher<? super T> baseMatcher;

    public LooseMatcherWrapper(Matcher<? super T> baseMatcher) {
        this.baseMatcher = baseMatcher;
    }

     <at> Override
    public boolean matches(Object item) {
        return baseMatcher.matches(item);
    }

     <at> Override
    public void describeMismatch(Object item, Description description) {
        super.describeMismatch(item, description);
    }

    public void describeTo(Description description) {
        baseMatcher.describeTo(description);
    }
}

With this wrapper we can infer actual type on assignment:
            Matcher<Map<String, String>> matcher =
wrap(hasEntry("test", "test"));
            oneOf(service).doSomethingWithAMap(with(matcher));

or specify type explicitly:
            oneOf(service).doSomethingWithAMap(with(TestUtil.<Map<String,
String>>wrap(hasEntry("test", "test"))));

All compiles and works. Not that smooth, due to java type inference
working only on assignment, but not from arguments of a method in
which generic method is called. So that seems to be the most of what
we can do with the wrap() method.

An alternative is to utilize with() method for type inference. Here I
added with_() method to custom expectations class (we don't wanna
touch existing with() method, so not to ruin its type inference
capabilities):
class MyExpectations extends Expectations {
    public <T> T with_(Matcher<? super T> matcher) {
        currentBuilder().addParameterMatcher(matcher);
        return null;
    }
}

Again, we can infer map type implicitly on assignment:
        context.checking(new MyExpectations() {{
            Map<String, String> map = with_(hasEntry("test", "test"));
            oneOf(service).doSomethingWithAMap(map);
        }});

or specify it explicitly:
        context.checking(new MyExpectations() {{
            oneOf(service).doSomethingWithAMap(this.<Map<String,
String>>with_(hasEntry("test", "test")));
        }});

 (actually, current Expectations implementation doesn't allow calling
with() before oneOf(), so the first example will throw
RuntimeException)

So, my suggestion is to add a method to JMock that allows downcasting
via type inference, so we could utilize "generic" matchers like
hasEntry() and containsInAnyOrder() for expectations:
public <T> T method(Matcher<? super T> matcher)

Regards,
Konstantin Fadeyev

> 28.05.2012, 13:33, "Steve Freeman" <steve@...>:
>
> sorry for the delay, replied on StackOverflow
>
> http://stackoverflow.com/questions/10704443/jmock-map-expectations/10782333#10782333
>
> There isn't a good answer to this as we hit the limits of Java generics. There's a tension between the
generics we need for jMock and what we need for assertThat()
>
> I tend to add a helper method, with an expressive name, to force the types.
>
>  <at> Test public void test() {
>   context.checking(new Expectations(){{
>     oneOf(service).doSomething(with(mapIncluding("test", "test")));
>   }});
>
>   main.run();
> }
>
>  <at> SuppressWarnings({"unchecked", "rawtypes"})
> private Matcher<Map<String, String>> mapIncluding(String key, String value) {
>    return (Matcher)Matchers.hasEntry(key, value);
> };
>
> Yes, this is pig-ugly. I can only apologise that this is the best we appear to be able to do. That said, it's
rare that I have to go as far as turning off the types, I can give it a name that's meaningful in the domain, and
I've localised the unchecking to the helper method.
> ---------------------------------------------------------------------
> 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

AUTO: Riazuddin Mohideen is out of the office. (returning 06/11/2012)