Develop Reference

Mocking a Predicate in Java using Mockito

I have a Predicate which checks for a row existence in Database.I am not sure if this is a good use of predicate but it made my code clean and concise.But when I am Tesing this code I am not able to mock the DAO class and not sure why is the case.
public class validator{
public Predicate<String> doesRowExists = fileName -> makeDao().isRowReturned(RowId);
public AlertFileDAO makeDataDao(){
return new DataDao();
}
public boolean validate(String RowId){
return doesRowExists.test(rowId)
}
}
//Test
public class ValidatorTest{
#setup
void beforeAll(){
mockValidator = spy(new Validator());
doReturn(mockDataDao)
.when(mockValidator)
.makeDataDao();
}
#Test
test_whenRowExists(){
new Validator.validate("1-abc-34");
}
When Im triggering the test it is hitting the actual DB and not using the mocked DAO class.Im not sure what exactly I am missing here.Please suggest.

Why don’t you simply inline the predicate and deliver the dao as constructor argument? This makes your api cleaner: method call vs getter for predicate and test on predicate you ended up with.
With your accepted answer, the user has to use the following:
validator.doesRowExist().test(rowId);
I believe the following would be easier to use:
validator.doesRowExist(rowId);
or even:
validator.validate(rowId);
Lets make a series of refactorings to achieve that:
Step 1:
You use your predicate to implement validate function. There are no other calls, nor passing to another functions (higher-order functions accepting a predicate are a typical use for them). Let's change the predicate to a method:
public class Validator {
public DataDao makeDataDao(){
return new DataDao();
}
public boolean validate(String rowId){
return doesRowExist(rowId);
}
private boolean doesRowExist(String rowId) {
return makeDataDao().isRowReturned(rowId);
}
}
Step 2:
Daos are typically singletons (one instance of them is enough). Depending on the frameworks you use, creating a Dao may be more costly than calling a method on it. Let's apply dependency injection principles (class receives it dependencies, not creates them):
public class Validator {
private final DataDao dataDao;
Validator(DataDao dataDao) {
this.dataDao = dataDao;
}
public boolean validate(String rowId){
return doesRowExist(rowId);
}
private boolean doesRowExist(String rowId) {
return dataDao.isRowReturned(rowId);
}
}
If you really need to create Dao each time, you can provide a fecory in the constructor.
Result:
Your class:
has nicer api
is likely more efficient
is trivially testable:
#ExtendWith(MockitoExtension.class)
public class ValidatorTest {
#Mock
DataDao mockDataDao;
#InjectMocks
Validator validator;
#Test
void whenValidateReturnsValueFromIsRowReturned(){
var rowId = "1-abc-34";
doReturn(false)
.when(mockDataDao)
.isRowReturned(rowId);
assertEquals(false, validator.validate(rowId));
}
}

I see your problem as example of more common task: how to stub a field. In your case, you need to stub field doesRowExists.
The common task has common solution: use getter instead: public Predicate<String> getDoesRowExists() { return doesRowExists;} or, with common code style, public Predicate<String> isRowExists() { return doesRowExists;}
So, in your production code you call getter instead field: return isRowExists().test(rowId)
In your test code you just mock this getter: when(isRowExists).thenReturn(true)

PowerMockito mocking static class INSIDE enum?

I have a enum that has to have a inner static class for bean injection.
I feel I'm facing the most difficult situation for a mock: enum, static class, static field, static method..
public enum Category{
C1(Something(Constants.getFactory().createSomething(""))),
C2(...);
public static Constants {
#Autowired
private static Factory factory;
public static Factory getFactory(){
return factory;
}
}
}
And my testing class using PowerMockito is:
#RunWith(PowerMockRunner.class)
#PrepareForTest({Category.class,Category.Constants.class})
public class CategoryTests {
#Before
public void setUp() throws Exception {
PowerMockito.mockStatic(Category.class);
PowerMockito.mockStatic(Category.Constants.class);
//This simply testing mock didn't work
//PowerMockito.when(Category.Constants
// .getFactory()).thenReturn("123");
//I tried to mock the inner field 'factory' and use it directly without a getter
//(with small changes in the original class)
//But it didn't work either
Factory factory = PowerMockito.mock(Factory.class);
NewClass newClass = PowerMockito.mock(NewClass.class);
PowerMockito.when(Factory.createSomething(anySring()))
.thenReturn(newClass);
Whitebox.setInternalState(
Category.Constants.class,"factory",Factory);
//This is like the most common way to stub
//It didn't work, so I believe the inner static class were never mocked
PowerMockito.doReturn(factory).when(Category.Constants.class,
"getFactory", anyString());
}
//I don't know if real test cases matter that much but I update to add it for reference.
#Test(dataProvider = "Case1")
public void testFromFilterType(final String testName, String input, final Category expected) {
assertEquals(Category.doSomething(input), expected);
}
#DataProvider(name = "Case1")
Object[][] fromFilterTypeCases() {
return new Object[][] {
{ "C1", "input1", Category.C1 },
{ "C2", "input2", Category.C2 },
};
}
}
//Currently the tests got skipped because in class Category Constants.getFactory().createSomething(""),
//where Constants.getFactory() returns null and mocking doesn't work.
At first I didn't mock the Enum, but just the static inner class. After heavily searching, I tried in all ways. The setup seems correct but it may miss some tricks. Any helps?

A bit of guessing: Category.class is the class you intend to test. That class itself contains nothing that should require mocking/preparation.
So: drop these parts in your code. Even if it doesn't cause your current issue, I am pretty sure that it might have all kinds of unwanted consequences when you start testing things later on.
Beyond that, the real answer would be to avoid the necessity for PowerMock(ito) in the very first place. You are already using #Autowired, which implies that you are using a DI framework. Most DI frameworks also have hooks for unit testing. So you should rather try to get #Autowired to work in your test setup.

How to design a class for unit tests

I have a Java class like the following:
public class MyClass {
/** Database Connection. */
private dbCon;
public MyClass() {
dbCon = ...
}
public void doSomethingWith(MyData data) {
data = convertData(data);
dbCon.storeData(data);
}
private MyData convertData(MyData data) {
// Some complex logic...
return data;
}
}
since the true logic of this class lies in the convertData() method, I want to write a Unit Test for this method.
So I read this post
How do I test a private function or a class that has private methods, fields or inner classes?
where a lot of people say that the need to test a private method is a design smell. How can it be done better?
I see 2 approaches:
Extract the convertData() method into some utility class with a public api. But I think this would be also bad practice since such utility classes will violate the single responsibilty principle, unless I create a lot of utility classes with maybe only one or two methods.
Write a second constructor that allows injection of the dbCon, which allows me to inject a mocked version of the database connection and run my test against the public doSomething() method. This would be my preferred approach, but there are also discussions about how the need of mocking is also a code smell.
Are there any best practices regarding this problem?

Extract the convertData() method into some utility class with a public api. But I think this would be also bad practice since such utility classes will violate the single responsibility principle, unless I create a lot of utility classes with maybe only one or two methods.
You interpretation of this is wrong. That is exactly what the SRP and SoC (Separation of Concerns) suggests
public interface MyDataConverter {
MyData convertData(MyData data);
}
public class MyDataConverterImplementation implements MyDataConverter {
public MyData convertData(MyData data) {
// Some complex logic...
return data;
}
}
convertData implementation can be now tested in isolation and independent of MyClass
Write a second constructor that allows injection of the dbCon, which allows me to inject a mocked version of the database connection and run my test against the public doSomething() method. This would be my preferred approach, but there are also discussions about how the need of mocking is also a code smell.
Wrong again. Research Explicit Dependency Principle.
public class MyClass {
private DbConnection dbCon;
private MyDataConverter converter;
public MyClass(DbConnection dbCon, MyDataConverter converter) {
this.dbCon = dbCon;
this.converter = converter;
}
public void doSomethingWith(MyData data) {
data = converter.convertData(data);
dbCon.storeData(data);
}
}
MyClass is now more honest about what it needs to perform its desired function.
It can also be unit tested in isolation with the injection of mocked dependencies.

How to spy on injected singleton?

I have a validation method in a model class that gets called from code that I don't have control over. This validation method has parameters that come from dependency injection. One of these parameters is a singleton (#Singleton) class.
#Singleton
public class ObjValidation {
#Inject
public ObjValidation() {
objsCache = new HashSet<>();
}
public boolean exists(String obj) {
return objsCache.contains(obj) || lookupObj(obj);
}
...
}
As you can see this singleton does perform a lookup on a database if the object isn't contained in the cache. While testing this database isn't there and should not be tested. Therefore I'm trying to mock the exists() method to return true without being run.
My first thought was, since this is a singleton, if I would inject the singleton into my test case before running it, I would create the singleton instance therefore could spy on it.
ObjValidation objValidation = spy(app.injector().instanceOf(ObjValidation.class));
doReturn(true).when(objValidation).exists(any());
But yes, spy only returns a copy and therefore doesn't spy on the instantiated singleton. I would need to replace the singleton instance with the spy copy to make it work this way.
How can I do this?
Further explanation of the test case:
In my test (method under test is register()) I bind a scala.html view form to a model class via the build in functionality of the play framework.
public Result register() throws ResultMessageException {
...
Form<Registration> filledRegistrationForm = this.formFactory.form(Registration.class).bindFromRequest();
...
}
The model has a validation method that has parameters that get injected as described in the play documentation: https://www.playframework.com/documentation/2.6.x/JavaForms#Custom-class-level-constraints-with-DI-support
#ValidateWithDI
public class Registration implements ValidatableWithDI<ValidationError> {
#Required
private String obj;
#Override
public ValidationError validate(ObjValidation objValidation) {
if (!objValidation.exists(obj)) {
return new ValidationError("obj");
}
return null;
}
}
This validation method gets called by the framework while binding the form.

Java constructor with Guice injected fields along with non-injected fields

I have a class which has a constructor where all the arguments are injected by GUICE.
Public class Order {
private final ClassOne classOneObj;
private final ClassTwo classTwoObj;
#Inject
public order(ClassOne classOneObj, ClassTwo classTwoObj){
this.classOneObj = classOneObj;
this.classTwoObj = classTwoObj;
}
}
Now, I want to add one more field(say, int status)variable which can't be injected.
Is it a good practice to create an object first with all the injected parameters and then set the new field which can't be injected with a setter method?
I came up with another approach where I created a factory class as given below:
public class OrderFactory {
private final ClassOne classOneObj;
private final ClassTwo classTwoObj;
#Inject
public order(ClassOne classOneObj, ClassTwo classTwoObj){
this.classOneObj = classOneObj;
this.classTwoObj = classTwoObj;
}
//getter methods for all the above variables
public ClassOne getclassOneObj(){
return classOneObj;
}
....
public Order createOrder(int status) {
return new Order(status, classOneObj, classTwoObj);
}
}
Then the new Order class will look like
public class Order {
int status
private final ClassOne classOneObj;
private final ClassTwo classTwoObj;
public order(int status, ClassOne classOneObj, ClassTwo classTwoObj){
this.status = status
this.classOneObj = classOneObj;
this.classTwoObj = classTwoObj;
}
//getter methods for all these member variables
}
Now to create the order object I will first create an OrderFactory object and then using the "createOrder" method I will create the Order object.
I am ending up with writing boilerplate code. Not sure if this is a good practice. Can anybody suggest on this if this approach is correct or there is any better approach for this problem?
I read in Google Guice and found there is a feature #Assisted for assisted injection for such cases. But I found that complex and couldn't convince myself whether I should go with that in my case.
Thanks in advance for any suggestion or guidance.

Your factory approach is excellent. Please don't use the setters: if the field can be made immutable, it should be immutable, whether or not it makes it "convenient" to instantiate.
Another approach you can take is Assisted Injection, which solves this exact problem. With that, you only define the factory interface, and its implementation is magically given to you by Guice:
class Order {
interface Factory {
Order create(Status status);
}
#AssistedInject Order(
ClassOne one,
ClassTwo two,
#Assisted Status status) {
}
}
Module code:
bind(Order.Factory.class).toProvider(
FactoryProvider.newFactory(Order.Factory.class, Order.class));
Then the clients inject Factory and use it just like they do in your example.

You're typically going to inject things that take some amount of effort to construct. If you're just injecting an int field, you'd be better off just calling a setter method on the object (that has some of it's more complex dependencies injected). Also, if a fields changes frequently, as implied by a field called "status", then it's also not a good candidate for injection.