How to use should_verify_with_at_least_and_fail method of org.mockitousage.verification.VerificationWithAfterTest class

Nutshell: Can't always use when to stub spies; use doReturn.

Assuming static imports of spy and doReturn (both PowerMockito):

@RunWith(PowerMockRunner.class)
@PrepareForTest(B.class)
public class BTest {
    @Test public void testClass() throws Exception {
        B b = spy(new B());
        doReturn(42).when(b, "m");
        b.asd();
    }
}

You could also @PrepareForTest(A.class) and set up the doReturn on when(a, "m"). Which makes more sense depends on the actual test.

ServletRequest, ServletResponse and FilterChain are all interfaces, so you can easily create test stubs for them, either by hand or using a mocking framework.

Make the mock objects configurable so that you can prepare a canned response to getRequestURI() and so that you can query the ServletResponse to assert that sendRedirect has been invoked.

Inject a mock ModeService.

Invoke doFilter passing the mock ServletRequest, ServletResponse and FilterChain as its parameters.

@Test
public void testSomethingAboutDoFilter() {
    MyFilter filterUnderTest = new MyFilter();
    filterUnderTest.setModeService(new MockModeService(ModeService.ONLINE));
    MockFilterChain mockChain = new MockFilterChain();
    MockServletRequest req = new MockServletRequest("/maintenance.jsp");
    MockServletResponse rsp = new MockServletResponse();

    filterUnderTest.doFilter(req, rsp, mockChain);

    assertEquals("/maintenance.jsp",rsp.getLastRedirect());
}

In practice you'll want to move the setup into an @Before setUp() method, and write more @Test methods to cover every possible execution path.

... and you'd probably use a mocking framework like JMock or Mockito to create mocks, rather than the hypothetical MockModeService etc. I've used here.

This is a unit testing approach, as opposed to an integration test. You are only exercising the unit under test (and the test code).

In JUnit, Parameterized tests use a special runner that ensure that the test is instantiated multiple times, so each test method is called multiple times. Mockito is a tool for writing specific unit tests, so there is no built-in ability to run the same test multiple times with different Mockito expectations.

If you want your test conditions to change, your best bet is to do one of the following:

• Parameterize your test using JUnit, with a parameter for the mock inputs you want;
• Run a loop of different parameters in your test, which unfortunately avoids the "test one thing per method" philosophy
• Extract a method that actually performs the test, and create a new @Test method for each mock you want.

Note that there's no prohibition on using mock objects as @Parameterized test parameters. If you're looking to parameterize based on mocks, you can do that, possibly creating the mock and setting the expectations in a static method on the test.

Note about runners: This Parameterized test runner conflicts with Mockito's MockitoJUnitRunner: Each test class can only have one runner. You'll want to switch to @Before and @After methods or a Mockito JUnit4 rule for your setup, if you use them both.

As an example, compressed from a different answer that explains more about Parameterized runners versus JUnit rules and lifting from the JUnit4 Parameterized Test doc page and MockitoRule doc page:

@RunWith(Parameterized.class)
public class YourComponentTest {
    @Rule public MockitoRule rule = MockitoJUnit.rule();
    @Mock YourDep mockYourDep;

    @Parameters public static Collection<Object[]> data() { /* Return the values */ }

    public YourComponentTest(Parameter parameter) { /* Save the parameter to a field */ }

    @Test public void test() { /* Use the field value in assertions */ }
}

When you mock an object using Mockito in Java. The framework doesn't change anything to the language specification. And in Java, the throws clause is defined at the compilation. You can't change the declared exceptions at runtime. In your case, if you call the method MyObject.call(), you have to handle the SomeException as in any normal Java code.

Since in unit test, you don't want to handle with things you are not testing. In your case, I would simply redeclare throws SomeException in the test method.

It looks like you're mocking out the only call you're making to production code.

In other words, your test says:

• When I call saveData(), fake the result to return true
• Now call saveData() - yay, the result was true!

None of your production code is being calls at all, as far as I can see.

The point of mocking is to mock out dependencies from your production class, or (sometimes, though I prefer not to) to mock out some methods of your production class that the code you're actually testing will call.

You should probably be mocking out the dependencies of Leaderboard rather than Leaderboard itself. If you must mock out saveData(), you should be testing the methods that call saveData()... check that they save the right data, that they act correctly when saveData() returns false, etc.

Mockito itself doesn't seem to be able to mock native methods according to this Google Group thread. However you do have two options:

1. Wrap the TableElement class in an interface and mock that interface to properly test that your SUT calls the wrapped insertRow(...) method. The drawback is the extra interface that you need to add (when GWT project should've done this in their own API) and the overhead to use it. The code for the interface and the concrete implementation would look like this:

   // the mockable interface
   public interface ITableElementWrapper {
       public void insertRow(int index);
   }
   
   // the concrete implementation that you'll be using
   public class TableElementWrapper implements ITableElementWrapper {
       TableElement wrapped;
   
       public TableElementWrapper(TableElement te) {
           this.wrapped = te;
       }
   
       public void insertRow(int index) {
           wrapped.insertRow(index);
       }
   }
   
   // the factory that your SUT should be injected with and be 
   // using to wrap the table element with
   public interface IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te);
   }
   
   public class GwtWrapperFactory implements IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te) {
           return new TableElementWrapper(te);
       }
   }
   

2. Use Powermock and it's Mockito API extension called PowerMockito to mock the native method. The drawback is that you have another dependency to load into your test project (I'm aware this may be a problem with some organizations where a 3rd party library has to be audited first in order to be used).

Personally I'd go with option 2, as GWT project is not likely to wrap their own classes in interfaces (and it is more likely they have more native methods that needs to be mocked) and doing it for yourself to only wrap a native method call is just waste of your time.

We are running JUnit test using following set-up:

i. Create test folder beside docroot in your portlet.

ii. Add unit folder to test and create your package in it.

iii. Create portal-ext.properties file in your test folder with following configuration:

jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost:3309/db_name?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=your_username
jdbc.default.password=your_password

jdbc.default.automaticTestTable=C3P0TestTable
jdbc.default.idleConnectionTestPeriod=36000
jdbc.default.maxIdleTime=1200

iv. Create a suite class (say AbcSuite.java) as following:

package x.x.x;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;

import com.liferay.portal.util.InitUtil;

@RunWith(Suite.class)
@Suite.SuiteClasses({
    // Where AxTest.class would be your test class name
    A1Test.class, A2Test.class, AxTest.class
})

public class AbcSuite {

    @BeforeClass
    public static void setUp() throws Exception {
        // Loading properties and establishing connection with database
        InitUtil.initWithSpring();
        System.out.println("X Portlet's Test Suite Execution : Started.");
    }

    @AfterClass
    public static void tearDown() {
        System.out.println("X Portlet's Test Suite Execution : Completed.");
    }
}

v. Create a test class (say A1Test.java) as following:

package x.x.x;

import java.util.ArrayList;

import org.junit.Assert;
import org.junit.BeforeClass;
import org.junit.Test;

public class A1Test {

    @BeforeClass
    public static void setUp() throws Exception {
        System.out.println("Test Running : A1Test");
    }

    @Test
    public void testAddAuthor() {
        Author author = AuthorLocalServiceUtil.createAuthor(
            CounterLocalServiceUtil.increment());
        author.setAuthorName("Testcase Author");
        author = AuthorLocalServiceUtil.addAuthor(author);

        Assert.assertNotNull(author);
        Assert.assertTrue(author.getAuthorId() > 0);
    }
}

That it! You can execute all test cases together using following command:

ant test -Dtest.class=AbcSuite*

or separately as:

ant test -Dtest.class=A1Test*

Mockito and RETURNS_DEEP_STUBS option might be what you're looking for. What's more, mockito seems often to return sensible values by default.

Example usage from the linked documentation, for quick reference:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

I find the most robust way to deal with time-critical code is to wrap up all of your time-critical functions in their own class. I usually call it TimeHelper. So this class might look like the following.

import java.util.Date;
public class TimeHelper{
    public long currentTimeMillis(){
        return System.currentTimeMillis();
    }
    public Date makeDate(){
        return new Date();
    }
}

and it might have more methods of the same type. Now, any class that uses such functions should have (at least) two constructors - the normal one that you'll use in your application, plus a package-private one in which a TimeHelper is a parameter. This TimeHelper needs to be stored away for later use.

public class ClassThatDoesStuff {
    private ThingConnector connector;
    private TimeHelper timeHelper;

    public ClassThatDoesStuff(ThingConnector connector) {
        this(connector, new TimeHelper());
    }

    ClassThatDoesStuff(ThingConnector connector, TimeHelper timeHelper) {
        this.connector = connector;
        this.timeHelper = timeHelper;
    } 
}

Now, within your class, instead of writing System.currentTimeMillis(), write timeHelper.currentTimeMillis(). This will, of course, have exactly the same effect; except now, your class has magically become much more testable.

When you test your class, make a mock of TimeHelper. Configure this mock (using Mockito's when and thenReturn, or alternatively doReturn) to return any time values you like - whatever you need for your test. You can even return multiple values here, if you're going to have multiple calls to currentTimeMillis() in the course of the test.

Now use the second constructor to make the object that you're going to test, and pass in the mock. This gives you perfect control of what time values will be used in the test; and you can make your assertions or verifications assert that precisely the right value has been used.

public class ClassThatDoesStuffTest{
    @Mock private TimeHelper mockTime;
    @Mock private ThingConnector mockConnector;
    private ClassThatDoesStuff toTest;

    @Test
    public void doesSomething(){
        // Arrange
        initMocks(this);
        when(mockTime.currentTimeMillis()).thenReturn(1000L, 2000L, 5000L);
        toTest = new ClassThatDoesStuff(mockConnector, mockTime);

        // Act
        toTest.doSomething();

        // Assert
        // ... ???
    }
}        

If you do this, you know that your test will always work, and never be dependent on the time slicing policies of your operating system. You also have the power to verify the exact values of your timestamps, rather than asserting that they fall within some approximate interval.