How to use StackTraceFilter method of org.mockito.internal.exceptions.stacktrace.ConditionalStackTraceFilter class

You do not need mockito to test this method, only a java.io.StringWriter.

Here is how you can write the test for a nominal use:

@Test
void status_written_in_csv_format() {
    // Setup
    WriteCsvToResponse objectUnderTest = new WriteCsvToResponse ();
    StringWriter stringWriter = new StringWriter();
    PrintWriter printWriter = new PrintWriter(stringWriter);

    // Given
    Status status = ...

    // When
    objectUnderTest.writeStatus(printWriter, status);

    // Then
    String actualCsv = stringWriter.toString();
    assertThat(actualCsv.split("\n"))
       .as("Produced CSV")
       .containsExactly(
         "id,storeId,status",
         "42,142,OK");
}

This example assume some things about your Status object, but you have the general idea. For assertions, I use AssertJ, but you can do the same with JUnit5 built-in assertions.

Hope this helps !

You can do that by instantiating your main class with parametrized constructor in your junit and then creating a spy from it.

Let's suppose your main class is A. Where B and C are its dependencies

public class A {

    private B b;

    private C c;

    public A(B b,C c)
    {
        this.b=b;
        this.c=c;
    }

    void method() {
        System.out.println("A's method called");
        b.method();
        c.method();
        System.out.println(method2());

    }

    protected int method2() {
        return 10;
    }
}

Then you can write junit for this using your parametrized class as below

@RunWith(MockitoJUnitRunner.class)
public class ATest {

    A a;

    @Mock
    B b;

    @Mock
    C c;

    @Test
    public void test() {
        a=new A(b, c);
        A spyA=Mockito.spy(a);

        doReturn(20).when(spyA).method2();

        spyA.method();
    }
}

Output of test class

A's method called
20

1. Here B and C are mocked object that you injected in your class A using parametrized constructor.
2. Then we created a spy of A called spyA.
3. We checked if spy is really working by modifying the return value of a protected method method2 in class A which could not have been possible if spyA was not an actual spy of A.

I think what you want is:

VendorObject vo = mock(VendorObject.class, new Answer() {
    @Override
    public Object answer(InvocationOnMock invocation) {

        // 1. Check if method exists on RedirectToObject.
        // 2a. If it does, call the method with the args and return the
        // result.
        // 2b. If it does not, throw an exception to fail the unit test.

    }
});

Of course, if you want to use this approach frequently, no need for the Answer to be anonymous.

From the documentation: "It's quite advanced feature and typically you don't need it to write decent tests. However it can be helpful when working with legacy systems." Sounds like you.

I think this happens because mockito doesn't know the semantic meaning of isEmpty() and when it encounters a boolean method mocks it with a default value that is false. Same think happens with size() but the default value here is 0.

Basically, you need to define the expected behaviour of your mocked object. If you don't, it will return default values.

The Mockito doc already shows an example of how to stub a parameterless void method with exceptions.

However, for stubbing a void method with parameters and exceptions, do this:

Since the return type of createAccount is void, you have to use doThrow:

User existingUser = ... // Construct a user which is supposed to exist
UserAccountManager accountMng = mock(UserAccountManager.class);    

doThrow(new Exception()).when(accountMng).createAccount(eq(existingUser));

Note the usage of the eq Matcher. If the argument's type (in this case User) does not implement equals on its own you can also try to use the refEq Matcher.

You should check out the exec-maven-plugin.

With the following configuration (notice the <systemProperties>)...

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.3.2</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>java</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <mainClass>com.example.Main</mainClass>
        <arguments>
            <argument>argument1</argument>
        </arguments>
        <systemProperties>
            <systemProperty>
                <key>hello.world</key>
                <value>Hello Stack Overflow!</value>
            </systemProperty>
        </systemProperties>
    </configuration>
</plugin>

...and the following class...

package com.example;
public class Main {
    public static void main(String[] args) {
        String prop = System.getProperty("hello.world");
        System.out.println(prop);
    }
}

...and running a package (notice the phase in the configuration - you can change if you want, maybe to install), it prints out the value Hello Stack Overflow! from the key hello.world. So basically, the plugin executes your program when you build.

See also the exec:exec goal. In the example, I used the exec:java goal, but the two are different in how they function.

exec:exec executes programs and Java programs in a separate process.

exec:java executes Java programs in the same VM.

UPDATE

Currently I am setting some values in properties based on the profile in my maven pom file. Is it possible to set this system property in the profile ? because really, i only have one pom file for dev and prod and its within the profile i would need to set it.

Yes, just use the ${property.name} in the <value> element of the system property element. For example:

<profiles>
    <profile>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <id>world</id>
        <properties>
            <hello.world>Hello World!</hello.world>
        </properties>
    </profile>
    <profile>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <id>stack</id>
        <properties>
            <hello.world>Hello Stack Overflow</hello.world>
        </properties>
    </profile>
</profiles>

And the plugin <systemProperties>:

<systemProperties>
    <systemProperty>
        <key>hello.world</key>
        <value>${hello.world}</value>
    </systemProperty>
</systemProperties>

Just by changing the profile, to either stack or world, the message will print Hello Stack Overflow or Hello World, respectively.

UPDATE 2

Another plugin is the properties-maven-plugin. Nothing's been done on it in a while, but from a few tests, the necessary functionality is there.

It has a set-system-properties goal along with some other useful goals to help ease properties management

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-2</version>
    <executions>
        <execution>
            <!-- any phase before your app deploys -->
            <phase>prepare-package</phase>
            <goals>
                <goal>set-system-properties</goal>
            </goals>
            <configuration>
                <properties>
                    <property>
                        <name>hello.world.two</name>
                        <value>Hello World!</value>
                    </property>
                </properties>
            </configuration>
        </execution>
    </executions>
</plugin>

Lenient mocks are what you want, if you can't just use a real UserKeychain.

Mockito.lenient().when(userKeychain.getUserStatus()).thenReturn(UserState.OK);
Mockito.lenient().when(otherUserKeychain.getUserStatus()).thenReturn(UserState.SUSPENDED);

Mockito is designed to replace systems where you can't use the real system in your test, particularly in systems that predictably invoke services instead of getting properties from data objects (or other idempotent actions). Because your system doesn't call those methods in a deterministic order, and because the calls aren't expensive and don't have side effects, I would recommend just going with the "lenient" option.

Imagine this case instead, where you are testing deleting user 1001:

when(userRpc.deleteUser(1001)).thenReturn(RPC_SUCCESS);
when(userRpc.deleteUser(1002)).thenReturn(RPC_SUCCESS);  // unnecessary

The test might pass if you ever delete the wrong user: Over-stubbing has masked a problem. Compare with this:

when(userRpc.fetchExpensiveUserDetails(1001)).thenReturn(user1001);
when(userRpc.fetchExpensiveUserDetails(1002)).thenReturn(user1002);  // unnecessary

Depending on what you're testing, this might be dangerous, but might not be so bad. Simulating a slow mobile network or with expensive data, maybe it is entirely against spec for you to fetch too much. However, in other cases, it may be acceptable. Finally, compare this case:

when(calculationResult.getRealComponent()).thenReturn(-1d);
when(calculationResult.getComplexComponent()).thenReturn(5);
when(calculationResult.getShortString()).thenReturn("-1 + 5i");

calculationResult looks an awful lot like a data object, and it is probably not a critical part of your test which of your methods to call or whether you're calling all of them. This is a case where Mockito's strict stubbing hinders you rather than helping you, and might be a case where you want to make some of those stubbings lenient. You might also choose to make the entire mock lenient, which particularly makes sense if you were to create a test helper method like stubCalculationResult(-1, 5) that prepared an entire object for you like that.

The only option better than that is to use a real object. In my example, if CalculationResult is an existing well-defined object, it may be lower risk overall to use a real one than to mock the behavior you believe at test-writing time to be correct. Similarly for your case, if you have access to a UserKeychain constructor that populates UserStatus etc, then it may be safer to use that in a test.

Though this might appear at first glance to be a slippery slope into turning a unit test into an integration test, I'd like to clarify that I'm recommending this only for data objects, which have no dependencies, and which ideally are immutable objects that have no methods with side-effects. If you use dependency injection, these are the type of single-implementation data holders that you would call new on rather than getting from your graph. This is also a good reason to separate your data objects so they are immutable and easy to construct, and to shift your services to consume those objects rather than giving methods to the data objects (favoring loginService.login(user) rather than user.login(loginService)).

See Update below: You don't need a Factory

If you are using Jersey 2, one solution would be to use Custom Injection and Lifecycle Management feature (with HK2 - which comes with the Jersey dist). Also required would be a Mocking framework of course. I'm going to use Mockito.

First create a Factory with mocked instance:

public static interface GreetingService {
    public String getGreeting(String name);
}

public static class MockGreetingServiceFactory 
                                     implements Factory<GreetingService> {
    @Override
    public GreetingService provide() {
        final GreetingService mockedService
                = Mockito.mock(GreetingService.class);
        Mockito.when(mockedService.getGreeting(Mockito.anyString()))
                .thenAnswer(new Answer<String>() {
                    @Override
                    public String answer(InvocationOnMock invocation) 
                                                      throws Throwable {
                        String name = (String)invocation.getArguments()[0];
                        return "Hello " + name;
                    }

                });
        return mockedService;
    }

    @Override
    public void dispose(GreetingService t) {}
}

Then use the AbstractBinder to bind the factory to the interface/service class, and register the binder. (It's all described in the link above):

@Override
public Application configure() {
    AbstractBinder binder = new AbstractBinder() {
        @Override
        protected void configure() {
            bindFactory(MockGreetingServiceFactory.class)
                               .to(GreetingService.class);
        }
    };
    ResourceConfig config = new ResourceConfig(GreetingResource.class);
    config.register(binder);
    return config;
}

Seems like a lot, but it's just an option. I'm not too familiar with the test framework, or if it has an mocking capabilities for injection.

Here is the full test:

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.core.Application;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import org.glassfish.hk2.api.Factory;
import org.glassfish.hk2.utilities.binding.AbstractBinder;
import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
import org.junit.Assert;
import org.junit.Test;
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

public class ServiceMockingTest extends JerseyTest {

    @Path("/greeting")
    public static class GreetingResource {

        @Inject
        private GreetingService greetingService;

        @GET
        @Produces(MediaType.TEXT_PLAIN)
        public String getGreeting(@QueryParam("name") String name) {
            return greetingService.getGreeting(name);
        }
    }

    public static interface GreetingService {
        public String getGreeting(String name);
    }
    
    public static class MockGreetingServiceFactory 
                                  implements Factory<GreetingService> {
        @Override
        public GreetingService provide() {
            final GreetingService mockedService
                    = Mockito.mock(GreetingService.class);
            Mockito.when(mockedService.getGreeting(Mockito.anyString()))
                    .thenAnswer(new Answer<String>() {
                        @Override
                        public String answer(InvocationOnMock invocation) 
                                                       throws Throwable {
                            String name = (String)invocation.getArguments()[0];
                            return "Hello " + name;
                        }

                    });
            return mockedService;
        }

        @Override
        public void dispose(GreetingService t) {}
    }

    @Override
    public Application configure() {
        AbstractBinder binder = new AbstractBinder() {
            @Override
            protected void configure() {
                bindFactory(MockGreetingServiceFactory.class)
                        .to(GreetingService.class);
            }
        };
        ResourceConfig config = new ResourceConfig(GreetingResource.class);
        config.register(binder);
        return config;
    }
    
    @Test
    public void testMockedGreetingService() {
        Client client = ClientBuilder.newClient();
        Response response = client.target("http://localhost:9998/greeting")
                .queryParam("name", "peeskillet")
                .request(MediaType.TEXT_PLAIN).get();
        Assert.assertEquals(200, response.getStatus());
        
        String msg = response.readEntity(String.class);
        Assert.assertEquals("Hello peeskillet", msg);
        System.out.println("Message: " + msg);
        
        response.close();
        client.close();
       
    }
}

Dependencies for this test:

<dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-grizzly2</artifactId>
    <version>2.13</version>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.0</version>
</dependency>

UPDATE

So in most cases, you really don't need a Factory. You can simply bind the mock instance with its contract:

@Mock
private Service service;

@Override
public ResourceConfig configure() {
    MockitoAnnotations.initMocks(this);
    return new ResourceConfig()
        .register(MyResource.class)
        .register(new AbstractBinder() {
            @Override
            protected configure() {
                bind(service).to(Service.class);
            }
        });
}

@Test
public void test() {
    when(service.getSomething()).thenReturn("Something");
    // test
}

Much simpler!

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());