CODEWITHSUNDEEP
javaunit-testingtestingjunitmockito
clD
clD

Reputation: 2611

Test Method Called Without Having Argument In Test Class

I have a class which takes a message with payload String. The payload is then split and used to create an Entity which is passed to DAOInterface to persist.

How can you test the call daoInterface.insert(entity) has been made?

To Mock the DAOInterface and then verify the call to DAO requires the entity in the test class i.e.

verify(daoInterface).insert(entity);

Is this bad design i.e. creating the entity at this stage? Should the Sting[] split be passed to the DAOImplementaion and initialized there. Example problem,

public class ServiceClass {

    @AutoWire
    private DAOInterface daoInterface;

    public void serviceMessage(Message<String> message) {

        MessageHeaders mh = new MessageHeaders(message.getHeaders());       
        String[] split = ((String) mh.get("payload")).split("_");

        code omitted
        ...

        String type = mh.get("WhatType");

        Entity entity = new Entity(split[0], split[1], split[2]);

        if (type.equals("one"))
        {
            daoInterface.insert(entity); //How to test?
        }
        else
        {
            if (type.equals("two"))
            {
                doaInterface.modify(entity); //How to test?
            }
        }
    }
}

Upvotes: 0

Views: 955

Answers (3)

Don Roby
Don Roby

Reputation: 41137

You can verify with Mockito Matchers.

If you only care that the method is called with some Entity, you can verify that with 

verify(daoInterface).insert(any(Entity.class));

If you care about which Entity, and the Entity class has an equals method, you can make an entity that should be equal to the one created and verify with

verify(daoInterface).insert(eq(expectedEntity);

If it's more complex than either of these cases, you can also write your own argument matchers.

Upvotes: 1

markspace
markspace

Reputation: 11020

If you use a test framework like PowerMock, you can invoke private constructors and private methods in your test. This makes it easy to inject mock objects like a mock DAOInterface so you can retrieve it later and test it's been called.

For example, in PowerMock, to call a private constructor:

public class ServiceClass{

        @Autowire
        private final DAOInterface dao;

        public ServiceClass() {
        }

        private ServiceClass(DAOInterface dao) {
                this.dao = dao;
        }


}

You simply do:

PrivateConstructorInstantiationDemo instance =  WhiteBox.invokeConstructor(
                                PrivateConstructorInstantiationDemo.class, 
                                new MockDAOInterface() );

So if you're using a dependency inject framework like above, this dovetails nicely. You don't normally have the dependency injection working during test, since it usually requires booting a large chunk of code with a lot of configuration.

By adding a single private constructor, you avoid breaking encapsulation, but you can still inject your mock object into the code during test with a test framework like PowerMock. This is considered best practice.

You could break encapsulation and add publicly accessible methods or ctors to the SeviceClass, but if you don't need them for your design it's not good practice to add them only for test. That's why people put such effort into bypassing encapsulation in frameworks like Mockito and PowerMock. It's not just a dodge around private code, it's because you want to keep the encapsulation while still being able to test.

EDIT:

If you're not familiar with making mock objects, you should do some Google searches on the subject. It's very common and a good skill to have. With the above code, you could make your own mock object. But making mocks is so common that most test frameworks will do this for you.

For example, in PowerMock, I just looked at their page on making mocks here. You can make a mock like this

DAOInteface myMock = createMock(DAOInterface.class);

You can then ask the mock to verify that methods are called:

expect(myMock.someMethod());

Now the mock 'expects' that method to be called, and if it isn't, it'll generate an error for your test. Pretty sweet actually.

You can also return values from a call:

expect(myMock.insert()).andReturn("Test succeeded");

so your code would then see the value "Test succeeded" when it called that method. I don't see that 'insert' does return a value, that's just an example.

Upvotes: 0

topr
topr

Reputation: 4612

The easiest thing you can do is injecting another collaborator to the service which will transform payload to Entity. This way you can keep control on object creation (Inversion of Control). Something like the example below injected to the ServiceClass should do the job:

interface PayloadTransformer {
    public Entity transform(String payload);
}

This way your code will be easy to test and you split responsibilities which is usually a good thing. Have a look on Single Responsibility principle

Pushing transformation logic down to dao is almost never a good idea.

BTW. you can write else if without additional brackets and indentations. It's more readable like:

if (a) {
    // do something
} else if (b) {
    // do something
} else {
    // do something
}

The last advice ServiceClass is really poor name for class. The word class is redundant here. Just name it Service, EntityService, MessageService or something which fits your case well. I wouldn't name field with suffix *Interface as well. Underneath is some implementation injected, I assume. Better name it entityDao or just dao. It's up to you though :)

Upvotes: 0

Related Questions