Archive

Posts Tagged ‘mockito’

Using Mockito’s Spy to mock hierarchical objects

July 6th, 2010 Shrihari No comments

Mocking in Mockito using mock() method is straight-forward for POJO(s) with no inheritance.  However for objects which are defined as part of class hierarchies, using mock() to alter parental behaviour cannot be implemented. Lets take an example of a base class such as Staff with derived classes: Employee and Contractor as given below:

public class Staff {
    protected String name;
    protected Integer age;
    protected String deptname;
    //other fields, setters and accessors.
}

The Employee/Contractor class look like this

public class Employee extends Staff {
   private String employeeID;
   private Date joinDate;
   //setters and accessors.
}

public class Contractor extends Staff {
    private String contractorID;
    private String fromCompany;
    private Long contractDuration'
    //setters and accessors.
}

Lets now mock Contractor object and stub the name (parental attribute) behaviour:

  Contractor contractor = mock(Contractor.class);
  when(contractor.getName()).thenReturn("John Smith");
  assertEquals(contractor.getName(), "John Smith");

Unfortunately the above code is not able to induce name behaviour using stubbing and assertEquals fails in the above code . Now Mockito provides spy() for creating pseudo mock on real objects. This indeed provides a breather to mock hierarchical objects as show below for the example we have

  Contractor contractor = new Contractor();
  contractor.setName("John Smith");
  Contractor mocked = spy(contractor);
  //other stubbing logic
  assertEquals(contractor.getName(), "John Smith");

This way we can alter functional behaviour for parental properties as well.

Categories: jee-light Tags:

Understanding Exception Handling on Mock objects

June 6th, 2010 Shrihari No comments

Mockito is the recommended and used mocking testing framework which provides varied function points to mock and verify interactions. It provides a parallel support to TestNG or JUnit for faster Test Driven Development (TDD) adoption in newer teams. In this edition of the write-up I would explore the concept of mocking with exception handling.

Lets consider a user credential validation login, before user getting authenticated into the system. If the credential validation fails, the system is expected to throw an application exception. However if it passes, the actual authentication to the system should
happen. With the familiarity with TestNG and Mockito, lets look the test case code

@Test(expectedException=UserValidationException.class)
public void testCredentialsValidation()
{  //create a mock to return false for validation - to fail login
UserCredentials credentials = mock(UserCredentials.class);
when(credentials.validate(anyString(),anyString())).thenReturn(false);

//Call the login service to gain entry
LoginService service = new LoginService(credentials);
service.loginuser("sample","sampl3");
}

Please note here that UserCredentials is only being mocked here, not the LoginService. The reason is to run the induced behaviour of the mocked UserCredentials on the actual LoginService functionality. A mocked object will behaviour only according to what has been induced.

Having looked at the test code, lets look at the actual logic implementation

public interface UserCredentials
{  public boolean validate(String username,String passwordtext);
}
public class LoginService
{  private UserCredentials credentials;

public LoginService(UserCredentials credentials)
{ this.credentials = credentials;
}

public void loginuser(String user, String passwd) throws UserValidationException
{   if(!credentials.validate(user,passwd))
throw new UserValidationException("Username or password invalid..");
//actual authentication process...
}
}
public UserValidationException extends RuntimeException
{  private String message;

public UserValidationException(String msg)
{   message = msg;
}
}

UserValidationException extends RuntimeException for brevity purposes, so that the test code signature is not affected. There is another methodology whereby we could induce behaviour of throwing an exception on the mocked object, even though the actual need not throw any exception.

doThrow(new UserValidation()).when(loginservice).loginuser(anyString(),anyString());

Unfortunately this is at the method level and not at the individual statement level. Am looking at options on mocking exceptions at the method  statement level for the mocked objects. Any thoughts!

Categories: jee-light Tags: ,