How to use some_class_with_parametered_constructor method of org.mockitousage.annotation.MockInjectionUsingConstructorTest class

Well, the common approach to data storage in Java is, as you noted, not at all very object-oriented. This is in and of itself neither bad nor good: "object-orientedness" is neither an advantage nor disadvantage, it's just one of many paradigms, that sometimes helps with good architecture design (and sometimes not).

The reason DAOs in Java aren't usually object-oriented is exactly what you want to achieve – relaxing your dependency on the database. In a better-designed language, that allowed for multiple inheritances, this, of course, can be done very elegantly in an object-oriented way, but with Java, it just seems to be more troublesome than it is worth.

In a broader sense, the non-OO approach helps decouple your application-level data from the way it is stored. This is more than (non-)dependency on the specifics of a particular database, but also the storage schemas, which is especially important when using relational databases (don't get me started on ORM): you can have a well-designed relational schema seamlessly translated into the application OO model by your DAO.

So, what most DAOs are in Java nowadays are essentially what you mentioned in the beginning – classes, full of static methods. One difference is that, instead of making all the methods static, it is better to have a single static "factory method" (probably, in a different class), that returns a (singleton) instance of your DAO, which implements a particular interface, used by application code to access the database:

public interface GreatDAO {
    User getUser(int id);
    void saveUser(User u);
}
public class TheGreatestDAO implements GreatDAO {
   protected TheGreatestDAO() {}
   ... 
}
public class GreatDAOFactory {
     private static GreatDAO dao = null;
     protected static synchronized GreatDao setDAO(final GreatDAO d) {
         final GreatDAO old = dao;
         dao = d;
         return old;
     }
     public static synchronized GreatDAO getDAO() {
         return dao == null ? dao = new TheGreatestDAO() : dao;
     }
}

public class App {
     void setUserName(final int id, final String name) {
          final GreatDAO dao =  GreatDAOFactory.getDao();
          final User u = dao.getUser(id);
          u.setName(name);
          dao.saveUser(u);
     }
}

Why do it this way as opposed to static methods? Well, what if you do decide to switch to a different database? Naturally, you'd create a new DAO class, implementing the logic for your new storage. If you were using static methods, you would now have to go through all your code, accessing the DAO, and change it to use your new class, right? This could be a huge pain. And what if then you change your mind and want to switch back to the old DB?

With this approach, all you need to do is to change the GreatDAOFactory.getDAO() and make it create an instance of a different class, and all your application code will be using the new database without any changes.

In real life, this is often done without any changes to the code at all: the factory method gets the implementation class name via a property setting, and instantiates it using reflection, so, all you need to do to switch implementations is to edit a property file. There are actually frameworks – like spring or guice – that manage this "dependency injection" mechanism for you, but I won't go into details, first, because it is really beyond the scope of your question, and also, because I am not necessarily convinced that the benefit you get from using those frameworks is worth the trouble integrating with them for most applications.

Another (probably, more likely to be taken advantage of) benefit of this "factory approach" as opposed to "static" is testability. Imagine that you are writing a unit test that should test the logic of your App class independently of any underlying DAO. You don't want it to use any real underlying storage for several reasons (speed, having to set it up, and clean up afterwards, possible collisions with other tests, the possibility of polluting test results with problems in DAO, unrelated to App, which is actually being tested, etc.).

To do this, you want a test framework, like Mockito, that allows you to "mock out" the functionality of any object or method, replacing it with a "dummy" object, with predefined behavior (I'll skip the details, because, this again is beyond the scope). So, you can create this dummy object replacing your DAO, and make the GreatDAOFactory return your dummy instead of the real thing by calling GreatDAOFactory.setDAO(dao) before the test (and restoring it after). If you were using static methods instead of the instance class, this would not be possible.

One more benefit, which is kinda similar to switching databases I described above is "pimping up" your DAO with additional functionality. Suppose that your application becomes slower as the amount of data in the database grows, and you decide that you need a cache layer. Implement a wrapper class, that uses the real DAO instance (provided to it as a constructor parameter) to access the database, and caches the objects it reads in memory so that they can be returned faster. You can then make your GreatDAOFactory.getDAO instantiate this wrapper, for the application to take advantage of it.

(This is called "delegation pattern" … and seems like a pain in the butt, especially when you have lots of methods defined in your DAO: you will have to implement all of them in the wrapper, even to alter behavior of just one. Alternatively, you could simply subclass your DAO, and add caching to it this way. This would be a lot less boring coding upfront, but may become problematic when you do decide to change the database, or, worse, to have an option of switching implementations back and forth.)

One equally broadly used (but, in my opinion, inferior) alternative to the "factory" method is making the dao a member variable in all classes that need it:

public class App {
   GreatDao dao;
   public App(final GreatDao d) { dao = d; }
}

This way, the code that instantiates these classes needs to instantiate the DAO object (which could still use the factory) and provide it as a constructor parameter. The dependency injection frameworks I mentioned above, usually do something similar to this.

This provides all the benefits of the "factory method" approach, that I described earlier, but, as I said, is not as good in my opinion. The disadvantages here are having to write a constructor for each of your app classes, doing the same exact thing over, and over, also not being able to instantiate the classes easily when needed, and some lost readability: with a large enough code base, a reader of your code, not familiar with it, will have hard time understanding which actual implementation of the DAO is used, how it is instantiated, whether it is a singleton, a thread-safe implementation, whether it keeps state, or caches anything, how the decisions on choosing a particular implementation are made etc.

You can achieve that with thenAnswer(), a feature Mockito documentation sees as controversial:

Yet another controversial feature which was not included in Mockito originally. We recommend using simple stubbing with toReturn() or toThrow() only. Those two should be just enough to test/test-drive any clean & simple code.

Here's thenAnswer:

private boolean called = false;

when(mock.nextItem()).thenAnswer(new Answer() {
 Object answer(InvocationOnMock invocation) {   
     called = true;       
     return item;
 }
when(mock.isEmpty()).thenAnswer(new Answer() {
 Object answer(InvocationOnMock invocation) {          
     return called;
 }
});

One of the problems with Mockito.when is that the argument you pass to it is the expression that you're trying to stub. So when you use Mockito.when twice for the same method call, the second time you use it, you'll actually get the behaviour that you stubbed the first time.

I actually recommend NOT using Mockito.when. There are many traps that you can fall into when you use it - quite a few cases when you need some other syntax instead. The "safer" alternative syntax is the "do" family of Mockito methods.

doReturn(value).when(mock).method(arguments ...);
doThrow(exception).when(mock).method(arguments ...);
doAnswer(answer).when(mock).method(arguments ...);

So in your case, you want

doThrow(new BadSqlGrammarException(??, ??, ??)).when(accountMapper).createBadGrammarException();

If you are starting out with Mockito, then I recommend that you learn to use the "do" family. They're the only way to mock void methods, and the Mockito documentation specifically mentions that. But they can be used whenever Mockito.when can be used. So if you use the "do" family, you'll end up with more consistency in your tests, and less of a learning curve.

For more information about the cases when you must use the "do" family, see my answer on Forming Mockito "grammars"

Handmade

As InitialContext doc says, you can provide your own factory for InitialContext objects, using java.naming.factory.initial system property. When the code runs inside application server, the system property is set by the server. In our tests, we provide our own implementation of JNDI.

Here's my Mockito only solution: I defined a custom InitialContextFactory class, that returns a mock of InitialContext. You customize the mock as you wish, probably to return more mocks on lookup calls.

public class PlainTest {
  @Mock InitialContextFactory ctx;
  @InjectMocks Klasa1 klasa1;

  public static class MyContextFactory implements InitialContextFactory
  {
    @Override
    public Context getInitialContext(Hashtable<?, ?> environment) throws NamingException {
      ConnectionFactory mockConnFact = mock(ConnectionFactory.class);
      InitialContext mockCtx = mock(InitialContext.class);
      when(mockCtx.lookup("jms1")).thenReturn(mockConnFact);
      return mockCtx;
    }
  }

  @Before
  public void setupClass() throws IOException
  {
    MockitoAnnotations.initMocks(this);
    System.setProperty("java.naming.factory.initial",
      this.getClass().getCanonicalName() + "$MyContextFactory");
  }

Spring (added by edit)

If you don't mind leveraging Spring Framework for testing purposes, here's their simple solution: SimpleNamingContextBuilder:

SimpleNamingContextBuilder builder = new SimpleNamingContextBuilder();
DataSource ds = new DriverManagerDataSource(...);
builder.bind("java:comp/env/jdbc/myds", ds);
builder.activate();

It's ok to put it in @Before or @BeforeClass. After activate(), jndi data will be pulled from spring dummy.

The answer is yes, you can, and there are basically two levels of doing this, based on the need of your test.

If you merely want to test the interaction with the mocked object, you can simply use the verify() method, to verify that the void method was called.

If your test genuinely needs the mocked object to modify parameters passed to it, you will need to implement an Answer:

EDITED to show proper form of using Answer with void method

doAnswer(new Answer() {
    @Override
    Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
        return null; // void method, so return null
    }
}).when(mock).someMethod();

In Java 8+, the above is simplified with a lambda:

doAnswer(invocation-> {
    Object[] args = invocation.getArguments();
    ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
    return null;
}).when(mock).someMethod();

When you say

@Mock
Fruit fruit;

You tell Mockito: the fruit variable should be an instance of Fruit. Mockito will dynamically create a class which implements Fruit (this class is Fruit$$EnhancerByMockitoWithCGLIB$$b8254f54), and create an instance of this class. There's no reason for this class to be an instance of AppleFruit, since you didn't tell Mockito that the object had to be of type AppleFruit.

Declare it as AppleFruit, and it will be of type AppleFruit.

I can only assume that you are looking for thenAnswer & Answer. With thenAnswer you can modify the arguments of the mocked method and also return a result from that method.

E.g:

Set<String> result = new HashSet<>();
result.add("123");

Mockito.when(mockedMtnService.getModelSearchStrings(Mockito.anyMap(), Mockito.anyObject())).thenAnswer(new Answer<Set>() {
    @Override
    public String answer(InvocationOnMock invocation) throws Throwable {
        Map<String,List<Object>> mapArg = (Map<String,List<Object>>)invocation.getArguments()[0];
        // do something with mapArg....
        return result;
    }
});

Or with Java 8 lambda:

Mockito.when(mockedMtnService.getModelSearchStrings(Mockito.anyMap(), Mockito.anyObject())).thenAnswer(invocation -> {
    Map<String,List<Object>> mapArg = (Map<String,List<Object>>)invocation.getArguments()[0];
    // do something with mapArg....
    return result;
});

You should use PowerMock if you want Foo to return the same instance of Bar when you call doSomething method on any instance of Foo. Here's an example:

@RunWith(PowerMockRunner.class)
@PrepareForTest(Foo.class)
public class FooMockAllInstanceTest {

    @Test
    public void testMockInstanceofObjectCreation() throws Exception {
        Bar mockBar = PowerMockito.mock(Bar.class);
        when(mockBar.sayHello()).thenReturn("Hi John!");
        PowerMockito.whenNew(Bar.class)
                .withNoArguments()
                .thenReturn(mockBar);

        Foo myFooOne = new Foo();
        assertEquals(mockBar,  myFooOne.doSomething("Jane"));

        Foo myFooTwo = new Foo();
        assertEquals(mockBar,  myFooTwo.doSomething("Sarah"));

        Baz bazOne = new Baz();
        assertEquals(mockBar, bazOne.doSomething("Sam"));

        Baz bazTwo = new Baz();
        assertEquals(mockBar, bazTwo.doSomething("Nina"));
    }
}

This example will return the same Bar object even when Baz is called. Here's the Baz class,

public class Baz {

    public Bar doSomething(String name) {
        Foo foo = new Foo();
        return foo.doSomething(name);
    }
}

Update 2

There's another slightly better way to test with PowerMock. Here it's,

@Test
public void testStubbingMethod() throws Exception {
    Bar mockBar = PowerMockito.mock(Bar.class);
    when(mockBar.sayHello()).thenReturn("Hi John!");

    PowerMockito.stub(PowerMockito.method(Foo.class, "doSomething",
            String.class)).toReturn(mockBar);

    Foo myFooOne = new Foo();
    assertEquals(mockBar, myFooOne.doSomething("Jane"));

    Foo myFooTwo = new Foo();
    assertEquals(mockBar, myFooTwo.doSomething("Sarah"));

    Baz bazOne = new Baz();
    assertEquals(mockBar, bazOne.doSomething("Sam"));

    Baz bazTwo = new Baz();
    assertEquals(mockBar, bazTwo.doSomething("Nina"));
}

First you need to create a mock m_contractsDao and set it up. Assuming that the class is ContractsDao:

ContractsDao mock_contractsDao = mock(ContractsDao.class);
when(mock_contractsDao.save(any(String.class))).thenReturn("Some result");

Then inject the mock into m_orderSvc and call your method.

m_orderSvc.m_contractsDao = mock_contractsDao;
m_prog = new ProcessOrdersWorker(m_orderSvc, m_opportunitySvc, m_myprojectOrgSvc);
m_prog.work(); 

Finally, verify that the mock was called properly:

verify(mock_contractsDao, times(1)).save("Parameter I'm expecting");