How to use can_remove method of org.mockito.internal.util.collections.HashCodeAndEqualsSafeSetTest class

Here is a solution that will work for you particular case:

First of all you need to create a PersonMixin since you cannot add the required annotations to the mock.

import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.JsonProperty;


@JsonAutoDetect(getterVisibility = JsonAutoDetect.Visibility.NONE, isGetterVisibility = JsonAutoDetect.Visibility.NONE)
public interface PersonMixin {

    @JsonProperty
    String getName();

    @JsonProperty
    Integer getAge();
}

Now, use the object mapper like the in following code and you will get the same result as when you serialize the real object:

Person mockPerson = mock(Person.class);
when(mockPerson.getName()).thenReturn(name);
when(mockPerson.getAge()).thenReturn(age);
objectMapper.addMixInAnnotations(Person.class, PersonMixin.class);
try {
    System.out.println(objectMapper.writeValueAsString(mockPerson));
} catch (JsonProcessingException e) {
    e.printStackTrace();
    System.err.println("Failed to serialize mock object.");
}

You can not force a subclass to override a method. You can only force it to implement a method by making it abstract.

So if you can not make myMotherClass abstract you can only introduce another superclass that extends myMotherClass and delegates to the method that must be implemented:

public abstract class EnforceImplementation extends myMotherClass {

        public final void myMethod(){
             implementMyMethod();
        }

        public abstract void implementMyMethod();
}

EDIT

I found another interessting way of solving the problem in the hemcrest api that is e.g. used by mockito.

public interface Matcher<T> extends SelfDescribing {

    /**
     * Evaluates the matcher for argument <var>item</var>.
     * <p/>
     * This method matches against Object, instead of the generic type T. This is
     * because the caller of the Matcher does not know at runtime what the type is
     * (because of type erasure with Java generics). It is down to the implementations
     * to check the correct type. 
     *
     * @param item the object against which the matcher is evaluated.
     * @return <code>true</code> if <var>item</var> matches, otherwise <code>false</code>.
     *
     * @see BaseMatcher
     */
    boolean matches(Object item);

    /**
     * This method simply acts a friendly reminder not to implement Matcher directly and
     * instead extend BaseMatcher. It's easy to ignore JavaDoc, but a bit harder to ignore
     * compile errors .
     *
     * @see Matcher for reasons why.
     * @see BaseMatcher
     */
    void _dont_implement_Matcher___instead_extend_BaseMatcher_();
}

The interface specifies a method _dont_implement_Matcher___instead_extend_BaseMatcher_. Of course it does not prevent others from implementing the Matcher interface, but it guides the developer in the right direction.

And the BaseMatcher class implements the _dont_implement_Matcher___instead_extend_BaseMatcher_ method as final

public final void _dont_implement_Matcher___instead_extend_BaseMatcher_() {
    // See Matcher interface for an explanation of this method.
}

Finally I think that this is a design problem, because the BaseMatcher obviouosly implements logic that every Matcher should implement. Thus it would have been better to make the Matcher an abstract class and use a template method.

But I guess they did it because it was the best compromise between bytecode compatibility and new features.

In short, you could use either one in most cases (especially in Java 8 or newer). any() is often more idiomatic to non-brittle Mockito tests, though there are some pragmatic reasons and some correctness reasons to use anyString or any(String.class). Beware: the full rationale delves deeply into Mockito matcher internals, Java type parameter inference, and a whole lot of hysterical raisins.

For primitives like anyFloat(), there is a very practical reason to prefer anyFloat() etc instead of any(): The latter will give you a NullPointerException. For Mockito syntax like when(floatAcceptor.acceptFloat(any())).then(/*...*/), Mockito will actually call your mocked floatAcceptor.acceptFloat(float) method, and calls to any() necessarily return null because Mockito matchers have to return a dummy value and Java doesn't tell Mockito enough for it to know to return a float-compatible value. Irrespective of Mockito, Java will try to unbox a null into a float and fail. (anyFloat() and any(Float.class) tell Mockito to expect a float, so they correctly return 0.0f.) If you know a value is a primitive, boxed or unboxed, it's safer to call the appropriate method. That reason goes away for List and String, which are objects through and through; Java will happily pass a null received from any.

Historically, any behaved identically to any(Class), anyString(), and anyList(Class); this was an important convenience, because Java 7 couldn't infer type arguments from parameters, so the alternative was (Foo) any() or ArgumentMatchers.<Foo>any(). Compared to those, any(Foo.class) is more readable. It gets even worse for Lists, because type literals don't support other types, so any(List.class) won't even work for List<Bar>; you'd need (List<Bar>) any(), or ArgumentMatchers.<List<Bar>>any(), but with anyList you can just write anyList(Bar.class) and be on your way. In all cases, the argument was entirely ignored, and to check types you'd need to use isA(Class) to do a reflective, null-rejecting, instanceof-style check.

However, two improvements happened that change this: Java 8 happily infers type arguments through parameters, so any() is much more usable, and Mockito corrected its syntax to appear more like English. In English, "any car" wouldn't likely include a bicycle or an empty parking spot, but in Mockito 1.x any(Car.class) would happily match invocations with a null or a Bicycle instance. Thus, in Mockito 2.x, any(String) and anyString() will only accept non-null Strings, as documented in GitHub issue #185. Same with all other any(Class) calls.

To top it all off, Mockito prefers flexible tests rather than brittle ones, so you are much more likely to see any() for an irrelevant Foo parameter than isA(Foo.class) or eq(new Foo()). Irrelevant parameters are ignored by convention, if changing them is unlikely to affect the behavior being tested. That said, anyString() and anyList() can be useful for readability when you know the argument isn't null, and can also help you keep track of long argument lists by failing to compile if your list changes in an incompatible way to the method you're calling.

So in summary: Use primitive methods for primitives, use any() as much as possible, but switch to any(Class), any(List), or any(String) if you want to check non-null types are correct, if you want to improve readability, or you need to maintain long frequently-changing argument lists.

You can read more on the semantics of any(), any(Class), and isA on this GitHub issues answer.

when(myObject.someMethod()).thenReturn(someMockObject);
// run test
verify(myObject, times(n)).someMethod();

See the documentation for more conversion examples.

My solution was to update my global ~/.gradle/gradle.properties file with the correct proxy settings:

org.gradle.daemon=true
systemProp.https.proxyHost=proxy.company.net
systemProp.https.proxyPort=8181
systemProp.http.proxyHost=proxy.company.net
systemProp.http.proxyPort=8181
systemProp.https.nonProxyHosts=*.company.com|localhost

this is in effect, the same as passing these as command line args to gradlew (./gradlew -Dhttp.proxyHost=xxx -Dhttp.proxyPort=xxx -Dhttps.proxyHost=xxx -Dhttps.proxyPort=xxx

Two more ways to do it (see my comment on the previous answer by @Tomasz Nurkiewicz):

The first relies on the fact that the compiler simply won't let you pass in something of the wrong type:

when(a.method(any(Class.class))).thenReturn(b);

You lose the exact typing (the Class<? extends A>) but it probably works as you need it to.

The second is a lot more involved but is arguably a better solution if you really want to be sure that the argument to method() is an A or a subclass of A:

when(a.method(Matchers.argThat(new ClassOrSubclassMatcher<A>(A.class)))).thenReturn(b);

Where ClassOrSubclassMatcher is an org.hamcrest.BaseMatcher defined as:

public class ClassOrSubclassMatcher<T> extends BaseMatcher<Class<T>> {

    private final Class<T> targetClass;

    public ClassOrSubclassMatcher(Class<T> targetClass) {
        this.targetClass = targetClass;
    }

    @SuppressWarnings("unchecked")
    public boolean matches(Object obj) {
        if (obj != null) {
            if (obj instanceof Class) {
                return targetClass.isAssignableFrom((Class<T>) obj);
            }
        }
        return false;
    }

    public void describeTo(Description desc) {
        desc.appendText("Matches a class or subclass");
    }       
}

Phew! I'd go with the first option until you really need to get finer control over what method() actually returns :-)

I have to strongly disagree with this question.

There is no justification for a mocking tool that limits design choices. It's not just static methods that are ruled out by EasyMock, EasyMock Class Extension, jMock, Mockito, and others. These tools also prevent you from declaring classes and methods final, and that alone is a very bad thing. (If you need one authoritative source that defends the use of final for classes and methods, see the "Effective Java" book, or watch this presentation from the author.)

And "initialising collaborators rather than injecting them" often is the best design, in my experience. If you decompose a class that solves some complex problem by creating helper classes that are instantiated from that class, you can take advantage of the ability to safely pass specific data to those child objects, while at the same time hiding them from client code (which provided the full data used in the high-level operation). Exposing such helper classes in the public API violates the principle of information hiding, breaking encapsulation and increasing the complexity of client code.

The abuse of DI leads to stateless objects which really should be stateful because they will almost always operate on data that is specific to the business operation. This is not only true for non-public helper classes, but also for public "business service" classes called from UI/presentation objects. Such service classes are usually internal code (to a single business application) that is inherently not reusable and have only a few clients (often only one) because such code is by nature domain/use-case specific. In such a case (a very common one, by the way) it makes much more sense to have the UI class directly instantiate the business service class, passing data provided by the user through a constructor.

Being able to easily write unit tests for code like this is precisely what led me to create the JMockit toolkit. I wasn't thinking about legacy code, but about simplicity and economy of design. The results I achieved so far convinced me that testability really is a function of two variables: the maintainability of production code, and the limitations of the mocking tool used to test that code. So, if you remove all limitations from the mocking tool, what do you get?

I found the answer on my own. I need to add

@InjectMocks
private ResourceManager resourceManager;

Then I need to run the test with this instance:

@RunWith(MockitoJUnitRunner.class)
public class ResourceManagerTest
{
    @Mock
    private JerseyClient jerseyClient;

    @InjectMocks
    private ResourceManager resourceManager;

    @Test
    public void testResultHandling() throws JsonGenerationException, JsonMappingException, IOException, ResourceException
    {
        TestEntity testEntity = new TestEntity();

        testEntity.setGet(true);
        testEntity.setTestAttribute("1stTest");

        when(jerseyClient.get(anyString())).thenReturn("{\"get\":true,\"testAttribute\":\"2ndTest\",\"message\":\"success\"}");   

        TestEntity result = (TestEntity)resourceManager.execute(testEntity, TestEntity.class);

        assertThat(result, is(notNullValue()));
        assertThat(result.getMessage(), is("success"));
        assertThat(result.getTestAttribute(), is("2ndTest"));
    }
}

And I can also use the "doReturn...when" pattern.

Here's what I've been doing to cope with the situation.

I use global imports on a new test class.

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
import static org.mockito.Matchers.*;

When you are finished writing your test and need to commit, you just CTRL+SHIFT+O to organize the packages. For example, you may just be left with:

import static org.mockito.Mockito.doThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.Matchers.anyString;

This allows you to code away without getting 'stuck' trying to find the correct package to import.