Test class with a new call in it with Mockito

Question

I have a legacy class that contains a new   call to instantiate a LoginContext     public class TestedClass     public LoginContext login String user  String password        LoginContext lc   new LoginContext  login   callbackHandler           I want to test this class using Mockito to mock the LoginContext as it requires that the JAAS security stuff be set up before instantiating but I m not sure how to do that without changing the login   method to externalize the LoginContext   Is it possible using Mockito to mock the LoginContext class

User · Answer

I happened to be in a particular situation where my usecase resembled the one of Mureinik but I ended-up using the solution of Tomasz Nurkiewicz.

Here is how:

class TestedClass extends AARRGGHH {
    public LoginContext login(String user, String password) {
        LoginContext lc = new LoginContext("login", callbackHandler);
        lc.doThis();
        lc.doThat();
        return lc;
    }
}

Now, PowerMockRunner failed to initialize TestedClass because it extends AARRGGHH, which in turn does more contextual initialization... You see where this path was leading me: I would have needed to mock on several layers. Clearly a HUGE smell.

I found a nice hack with minimal refactoring of TestedClass: I created a small method

LoginContext initLoginContext(String login, CallbackHandler callbackHandler) {
    new lc = new LoginContext(login, callbackHandler);
}

The scope of this method is necessarily package.

Then your test stub will look like:

LoginContext lcMock = mock(LoginContext.class)
TestedClass testClass = spy(new TestedClass(withAllNeededArgs))
doReturn(lcMock)
    .when(testClass)
    .initLoginContext("login", callbackHandler)

and the trick is done...

User · Answer

In situations where the class under test can be modified and when it s desirable to avoid byte code manipulation  to keep things fast or to minimise third party dependencies  here is my take on the use of a factory to extract the new operation    public class TestedClass        interface PojoFactory   Pojo getNewPojo           private final PojoFactory factory           For use in production - nothing needs to change         public TestedClass             this factory   new PojoFactory                  Override             public Pojo getNewPojo                     return new Pojo                                            For use in testing - provide a pojo factory         public TestedClass PojoFactory factory            this factory   factory             public void doSomething             Pojo pojo   this factory getNewPojo            anythingCouldHappen pojo             With this in place  your testing  asserts and verify calls on the Pojo object are easy   public  void testSomething         Pojo testPojo   new Pojo        TestedClass target   new TestedClass new TestedClass PojoFactory                      Override                 public Pojo getNewPojo                         return testPojo                                        target doSomething        assertThat testPojo isLifeStillBeautiful    is true        The only downside to this approach potentially arises if TestClass has multiple constructors which you d have to duplicate with the extra parameter   For SOLID reasons you d probably want to put the PojoFactory interface onto the Pojo class instead  and the production factory as well   public class Pojo        interface PojoFactory   Pojo getNewPojo           public static final PojoFactory productionFactory            new PojoFactory                  Override              public Pojo getNewPojo                     return new Pojo

User · Answer

I am all for Eran Harel s solution and in cases where it isn t possible  Tomasz Nurkiewicz s suggestion for spying is excellent  However  it s worth noting that there are situations where neither would apply  E g  if the login method was a bit  beefier    public class TestedClass       public LoginContext login String user  String password            LoginContext lc   new LoginContext  login   callbackHandler           lc doThis            lc doThat            return lc                and this was old code that could not be refactored to extract the initialization of a new LoginContext to its own method and apply one of the aforementioned solutions   For completeness  sake  it s worth mentioning a third technique - using PowerMock to inject the mock object when the new operator is called  PowerMock isn t a silver bullet  though  It works by applying byte-code manipulation on the classes it mocks  which could be dodgy practice if the tested classes employ byte code manipulation or reflection and at least from my personal experience  has been known to introduce a performance hit to the test  Then again  if there are no other options  the only option must be the good option    RunWith PowerMockRunner class   PrepareForTest TestedClass class  public class TestedClassTest         Test     public void testLogin             LoginContext lcMock   mock LoginContext class           whenNew LoginContext class  withArguments anyString    anyString    thenReturn lcMock           TestedClass tc   new TestedClass            tc login   something    something else               test the login s logic

User · Answer

Not that I know of  but what about doing something like this when you create an instance of TestedClass that you want to test   TestedClass toTest   new TestedClass         public LoginContext login String user  String password              return mocked LoginContext            Another option would be to use Mockito to create an instance of TestedClass and let the mocked instance return a LoginContext

User · Answer

For the future I would recommend Eran Harel s answer  refactoring moving new to factory that can be mocked   But if you don t want to change the original source code  use very handy and unique feature  spies  From the documentation   You can create spies of real objects  When you use the spy then the real methods are called  unless a method was stubbed   Real spies should be used carefully and occasionally  for example when dealing with legacy code   In your case you should write  TestedClass tc   spy new TestedClass     LoginContext lcMock   mock LoginContext class   when tc login anyString    anyString     thenReturn lcMock

User · Answer

You can use a factory to create the login context  Then you can mock the factory and return whatever you want for your test   public class TestedClass     private final LoginContextFactory loginContextFactory     public TestedClass final LoginContextFactory loginContextFactory        this loginContextFactory   loginContextFactory         public LoginContext login String user  String password        LoginContext lc   loginContextFactory createLoginContext           public interface LoginContextFactory     public LoginContext createLoginContext

User · Answer

public class TestedClass       public LoginContext login String user  String password            LoginContext lc   new LoginContext  login   callbackHandler           lc doThis            lc doThat                -- Test Class        RunWith PowerMockRunner class       PrepareForTest TestedClass class      public class TestedClassTest             Test         public void testLogin                 LoginContext lcMock   mock LoginContext class               whenNew LoginContext class  withArguments anyString    anyString    thenReturn lcMock     comment  this is giving mock object   lcMock               TestedClass tc   new TestedClass                tc login   something    something else         testing this method                 test the login s logic                   When calling the actual method tc login   something    something else    from the testLogin     - This LoginContext lc is set to null and throwing NPE  while calling lc doThis

[java] Test class with a new() call in it with Mockito

Examples related to java

Examples related to unit-testing

Examples related to junit

Examples related to mockito