How to mock/stub void methods using PowerMock

Ok, I had though that the previous post would be the last post in the how-to series, but there are so many features in PowerMock that I am tempted to write more about it :)

So, here comes another post on how to mock/stub void methods using PowerMock.

One would think why are void methods so special, that we need a post to explain them?

Well thats because they are void methods. They don't return anything. If you remember, from my earlier post, the syntax of stubbing any method with a non void return type is as follows

In the above example doSomething method of ServiceA instance returns a String.

But imagine what will be the syntax, if doSomething method's return type was void!

May be something like this?

But, if you think for a moment about the above syntax, we would realize that  

methods in java are not very happy to accept void as the argument type!

Effectively, in the above syntax the when method is taking void as one of the argument!

Well this is a problem. This cannot happen!  Hence, we need a special syntax to mock/stub void methods.

So without wasting any more time lets look at the code under test:

In our example we want to test the persistCustomer method of the CustomerController. This method simply calls persist method on the Customer instance passed as argument. Assuming that the persist method of the Customer class returns nothing if everything is fine and throws a RuntimeException if something horribly goes wrong.

We want to write the test case for both these scenarios. So how do we do it?

How will we test it - How do they do it!:

Well, there is always a way with PowerMock!

Our first scenario is to verify that the persistCustomer method returns true if everything goes fine.

PowerMock uses the following syntax to stub the void method to do nothing.


If we read the syntax in pure English it says,

Do nothing when persist method is invoked on customer instance

As simple as that! We are telling the mock customer object to do nothing when persist method is invoked.

Lets look at the test case:


Now the other scenario, we want to make sure that false is returned when an exception is thrown from the persist method of customer instance, but for that to happen we have to stub the persist method of customer to throw an exception.

This is how we do it:

Syntax in English:

Throw RuntimeException when persist method of customer instance is invoked.

Lets look at the test case:

Thats it! Well you see there always is an easy solution with PowerMock

How to use custom argument matchers using PowerMock

We have come a long way and most likely this will be the last post in the series of how-to do stuff using PowerMock's (Mockito api) - Mocks on Steroid!

Some of the posts in the how-to series are more exotic then the others, but if you want to experience the real power of PowerMock, have a look at testing the UN-testable code.

In the previous post, we saw how we could use various argument matches, in situation when we don't know exactly what argument will be passed. Mockito already has a rich set of matchers but, if you think that is not enough we can write our own Matchers.

Why would you need them? Good question. In most cases the build in matchers are enough, but we might need custom matches when we want to make sure that a certain property of a certain class is set to a certain value.

Well did you understand that above sentence? No? Even I didn't understand that :)

As people say

Picture says a thousand words

my version of the same quote is

Code says everything

So lets look at the code under test.

Look at the argument passed to calculateChargeAmount method.  ServiceA's calculateChargeAmount passes a new instance of Calender to this method.

Of-course by now you already know how to test such a code. But since this post is about custom argument matchers, we will try to write a test for this method using the custom argument matcher.

But how do we write a custom argument matcher?

How will we test it - How do they do it!:

Well, turns out Mockito has a class called ArgumentMatcher. To create a custom matcher we extend the class ArgumentMatcher and override the matches method which returns a boolean.

If the matches method returns

• true: means that the argument passed matches the criteria
• false: means that the argument passed does not match the criteria

Along with this we need to use an argument matcher called argThat provided by Mockito. This argument matcher takes in an instance of our custom matcher, which will in-turn decide whether the argument passed matches our criteria.

Lets say in our example, we just want to make sure that the Calendar instance passed to the calculateChargeAmount method represents a date in the future.

This is how we could make use of the custom matcher in this case

Thats it folks! This is how we write custom argument matcher using Mockito.

It has been a pleasure doing this how-to series. I hope you guys have liked reading it as much as I have liked writing about it!

How to suppress fields with PowerMock

Now why would you want to do that! Lets look at the code straightaway.

Code under test:

The AccountDAO class has a "session" field, which has been initialized where its declared. Assuming that Session class in our example, is a wrapper over the the Hibernate Session class which talks to the database and does stuff for us.

BTW I couldn't agree more that its a terrible design!

So, basically what we want is to suppress the field "session" and instead use a stubbed Session instance.   Which means, we would stub out the getSession method, to write good unit-test case for the findAccount method.

So how do we suppress the field "session"

How would we test it - How do they do it!

The suppress method (which we had a look in the earlier post) can not only suppress the methods but can also suppress fields.


The Syntax:

What does the above syntax mean? Just read the line in plain English and that is exactly what it means!

Suppress the field of AccountDAO class called "session"

After this statement if we call getSession on any instance of AccountDAO it will always return null.

Q: But how can PowerMock do it?
A: Via byte code manipulation.  Remember our old friend @PrepareForTest(AccountDAO.class) annotation.

So we have solved one part of the problem. The next problem is to return a stubbed session instance when getSession method of AccountDAO is called. How can we do that?
A: Remember partial mocks via the spy method

That makes the problem look much simpler right?

So lets look at the test code:

Yes! We have managed to suppress a field for any given class.

Really, PowerMock's (using the Mockito api) keeps dazzling us with its Power!

How to supress methods and constructors using PowerMock

We have come a long way in our how-to series, demonstrating the power of PowerMocks (with the Mockito api).  I hope you are liking it as much as I like writing about it!

In the earlier post we saw how we could partly mock classes and its private methods using PowerMocks.  Today I will demonstrate how we could suppress a constructor and a method.

Now you must be thinking why the hell would I every want to do that!  Well believe me there are cases where you would want to do that :)  And we are about to have a look at one

Code under test:

Now you understand why we might need to suppress a constructor?  Well as we can see in the above code class LegacyCustomer's constructor simply throws RuntimeException (this is just a place holder.  In real world it might do some complicated operation may be loads a native library, establishes a connection to the db god knows what all it can do!).  Customer class extends LegacyCustomer class to add some more behavior to it (I am so making it up!).  In real life, I would never write such code.  Believe me!

But lets assume for now that we want to write a test case to verify that, when the Customer object is created it sets the email field to the value passed as argument.

So how do we test this?

How will we test it - How do they do it!:

We can easily suppress the constructor of LegacyCustomer class.
"Suppress a constructor" means that the code in the constructor will not be called and thats exactly what we want.  The syntax to do that is

Lets read the above line in English.

Suppress the constructor of LegacyCustomer class which takes one argument of String type.  Nice job!

This is step 1 of the process.

Now, if you think for a moment, base class constructor will be invoked automatically when derived class instance is created right!  Hence, in this case LegacyCustomer class's constructor will be invoked as soon as we create an instance of Customer class.

We dont want that to happen!
We want to suppress the call to the constructor of LegacyCustomer class.  So we will have to change the byte code of Customer class and tell it not to invoke the Constructor of LegacyCustomer class.

How do we do that?  Well, you know the answer to that using the following line of code

PowerMocks is happy to do the all byte code manipulation for us, we just need to tell it to do so.  This is done via our very own @PrepareForTest annotation.

So lets look at the entire test case

Simple?

Want more?

What if, I wanted to test a method in Customer class that actually invokes another method that does some complicated stuff?

Lets look at the code to test:

Well its basically the same code as above we have just added the getNetAssetValue method to the Customer class and we want to test this method.

How do we test it - How do they do it!

One way to do that is of-course by using spy and then stubbing the private method.

The other way is to suppress the call to doSomeComplexCalculation method.  What is the syntax for doing that?

Again, lets try to read the above syntax in English language.

Suppress the method of Customer class whose name is doSomeComplexCalculation. 

 Nice!

Lets look at the complete test case


That's all folks!

Looks like now we know how to suppress any constructor or a method!  Well, what if we wanted to test some method in LegacyCustomer class?  Remember the LegacyCustomer class constructor throws a RuntimeException.

Hummmm, that's interesting how can we suppress the constructor of class under test.  Turns out there are two ways of doing it.  One of the way is what we have just seen, using the suppress method.  Will show the other way in the next post.

Till then, Have Fun with PowerMocks!

How to partially mock a class and its private methods using PowerMock

Earlier, in the how-to series we had seen how-to mock constructors.  In this post we will have a look at how-to partially mock classes and even their private methods using PowerMocks - Mocks on Steroids!

Lets first look at the code to test before I start with my rambling

Code under test:

We want to write a test case to test method1 of ServiceA class.  ServiceA's method1 invokes method2.  method2 performs some complicated business logic - in this case creates an instance of ServiceB and invoked doBusinessOperation on that instance.

There are two approaches to test ServiceA's method1.

• Write the test case to mock out the ServiceB's constructor and assert that doBusinessOperation method was invoked on the mocked ServiceB object.
• Stub the method2 call!  Only verify that from method1 a call was made to the method2.

We already know how to write tests for the first approach.  Today we are more interested in looking at how do we write tests for the second approach.

Why would we ever choose the second approach over the first approach?  May be because method2 was already tested in some other test case.  Hence, we just want to make sure that method1 calls method2 with the right arguments.

So how do we partially mock ServiceA?

How will we test it - How do they do it!:

PowerMockito class provides a method called spy to create partial mock of a class.  This method takes an instance of the class that you want to partially mock as argument (in this case ServiceA).  Why? Because we want to invoke actual implementation of method1 and mock only method2.

Syntax

Then, we want to stubb out the method2 and return some dummy value.  This how its done

Notice the difference in the syntax then the regular when-theReturn syntax.  As, if we use the when-thenReturn syntax actual call to method2 will be made!  Why? Because PowerMocks does not know whether you are setting up an expectation on a partial mock or actually invoking the method.  Hence, be careful with partial mocks and choose the right syntax.

How to verify that the method was actually called?

No surprises here.

The full test case would look like:

A variation of the above example, what if the method2 was private?  Can we still stub it?  Of-course the right answer is YES!

Code under test:

How will we test it - How do they do it!:

Now, the above doReturn-when-method2 syntax wont work.  As method2 is private and is not accessible outside the scope of the class.  How do we stub it then?

Only change is, we pass in the name of the private method to stub as string argument to when method.  when method also accepts the var args array of arguments to the method2.

To verify that the private method2 was invoked use

Here also, instead of verify we use verifyPrivate and call a invoke method which accepts, name of the private method and its arguments.

Full test case would look like this:

Yes!  Thats it.  We have achieved what we intended to do!  PowerMock's is really a valuable tool to have in once arsenal!

Testing the Untestable code using PowerMock (Mockito api)

Taking inspiration from this excellent post by Johan Haleby, today I am going to jump a few gears and show you the real power of PowerMocks.  I will show you how can we write good unit-tests to test the untestable code!

We will continue the How-To series using PowerMocks (Mockito api) but today lets look at something more complicated.

You must be thinking, if the code is untestable then how can we write unit-tests?  But, that my friend is the real power of PowerMocks, we can write unit-tests for testing untestable code as well!

So What are we testing today.

Code to Test:

The code example is taken from one of the code samples of JMockit unit-testing framework (which by the way is another powerful unit-testing framework).  At first glance the code might not look as complicated, but make a note of the following points and then think how will you ever write a unit-test for doBusinessOperationXyz method?

• The ServiceA class is final
• It invokes a static method on Database class called find which returns a list
• It then creates a new instance of ServiceB class and invokes computeTotal method, passing it items retrieved from Database.find call
• ServiceB class is final as well
• Invokes another static method on Database class called save, passing it the EntityX instance

Wow! it seems like a really tough class to test.  Lets move ahead and write some good unit-tests to test the above code!

How will we test it - How do they do it!:

You will be surprised to know that, we could write multiple unit-tests for the above code depending on what exactly we want to test!  How awesome!

Test Requirement 1:

Lets say we want to test that, the ServiceB was invoked to compute total.

Test Code:

As usual we have to annotate the TestCase with @RunWith annotation (go here know more on why we have to do so).

We can verify that computeTotal method was invoked on ServiceB instance via a mocked ServiceB object. But if you think about this for a moment, how can we do that?  Because ServiceA's doBusinessOperationXyz is actually instantiating ServiceB.

How can we suppress this behavior and inject our mocked ServiceB object?  Simple! via byte-code manipulation of ServiceA class :)

No no, don't worry, we don't have to do byte-code manipulation on our own, PowerMocks does that for us.  All we need to tell PowerMocks is for which classes we want to perform byte-code manipulation using the @PrepareForTest annotation (go here to know more about @PrepareForTest annotation).

Another point is we want to mock static methods in Database class as well.  Hence we have to use @PrepareForTest annotation for Database class as well.

And finally, note that since we want to mock ServiceB class, which is a final class we have to use @PrepareForTest annotation for ServiceB class as well.

Enough fluff, show me the stuff!

The unit-test code looks like this

Thats all folks!  We have successfully tested the Untestable code for our first requirement


Thats all folks!  We have successfully tested the Untestable code for our first requirement

Test Requirement 2:

Lets say we want to test that, the Database was used to save EntityX.

Test Code:

Now that you have read the post so far, this one must look straightforward to you!

The test-case looks like

Thats it!

Test Requirement 3:

Database find was invoked to get the list of EntityY

Test Code:

The test-case looks a lot similar to the previous example

I promise its not much after this.

Test Requirement 4:

Should verify that EntityY list returned from Database.find was used to computeTotal

Test Code:

This is the final one.

Test Requirement 5:

Should verify that computed total was set on EntityX instance

Test code:

Done!  Its pretty evident from the above examples that testing the Untestable code is pretty easy using PowerMocks (Mockito api)

Feedback, questions and comments are welcome as usual!

How to mock final methods and classes using PowerMock

This is the second post in the how-to series of using PowerMockito to write beautiful unit-tests. In my previous post we saw how can we write unit-tests for mocking static methods.

Today, I will demostrate how we can mock final class and final methods using PowerMocks (Mockito api) - Mocks on steroids!

Requirement:

I am going to take a ficticious example, were AnotherService class's invokeFinal() method invokes a final method on the instance of FinalService class which is a final class.

Code under test:

The final method doSomething in the final Class FinalService does nothing, just throws an exception.  AnotherService's invokeFinalMethod invokes doSomething method.

Most common mocking framework in the java world cannot mock final classes/methods because they are typically based on creating proxies.  Creating proxies for final classes is not possible as we cannot subclass a final classes.

So how we do we it in PowerMocks (Mockito api)?

How will we test it - How do they do it!:

Aha! Its tad simple.  We don't need to do anything special here.

We have to use @PrepareForTest annotation with FinalService so that PowerMocks can actually mock FinalService (Go Here for explanation on @PrepareForTest).  Next up, we need to create the stub of FinalService using the following code

Then, we have two approaches

• We can either stub doSomething method and assert that the return value is what we expect (State based testing)
• We can verify that the doSomething method was actually invoked (Interaction based testing)

I will show both the approaches

State based testing:

Interaction based testing:

Thats it!

It is needless to say that things look pretty easy with PowerMocks (Mockito api).  They look easy because they are easy with PowerMocks!  Yes! you can with PowerMocks (Mockito api)!

Feedback, questions and comments are always welcome.

How to mock static methods using PowerMock

OK, what are we up to today!  Today I will demonstrate how can we write unit test for a class that invokes a static method on another class to get some work done using PowerMocks (Mockito api) - Mocks on steroids! 

Yeah, Yeah I know, I know implementing functionality using static methods is bad and stuff like that.  But sometimes you just can't help it as its not in your control.  Hence, as all wise man (woman included) say, better deal with it!

We have not yet seen how we could mock normal classes and interface and directly looking at how to mock static methods.  Well as Mr. IronMan said

Sometimes you gotta run before you can walk.

Currently, I am working on a project that uses Spring Roo.  Roo uses a lot of AspetJ goodness.  It adds a lot of static methods to domain objects via AspectJ, making the domain objects richer.  For e.g. In a domain Class Customer it would add methods like findCustomer, findAllCustomers, countCustomers etc.  If you are interested in exploring more about Spring Roo, start here.

Spring Roo uses Spring MVC as the web layer.  Hence, I am going to take example of CustomerController (a controller that does CRUD on Customer domain object).  Enough history, lets see the real stuff!

Requirement:

When user requests to see the customer information, CustomerController should find the requested Customer and return that in the model.

Controller Code:

The controller code would look like

Not showing the Spring MVC specific annotations.  Here, findCustomer is the method added by Spring Roo to the Customer domain class.  This is a static method which  is invoked by CustomerController to get the requested Customer instance.  This is what we want to test. 

How will we test it - How do they do it!:

As I explained in my previous post, PowerMocks uses custom class-loader and byte-code manipulation to enable mocking of static methods.  PowerMocks does this by using the following annotations

• @RunWith -- PowerMocks uses a custom Runner called PowerMockRunner.  This is done so that 
• PowerMocks could show informative message if an exception is thrown from the test
• PowerMocks could notify listeners of certain events.  For e.g. before the test methods start executing an event BeforeTestMethod is triggered.  Don't worry, if you don't understand this.  Its a little advanced stuff.  Just remember, that we need to use a Custom runner.
• @PrepareForTest -- This annotation tells PowerMock to prepare certain classes for testing. Classes needed to be defined using this annotation are typically those that needs to be byte-code manipulated. This includes final classes, classes with final, private, static or native methods that should be mocked

That's about all the annotations you will need!  Next we will have to tell PowerMocks that we want to mock static methods of which class.  This is done using

We are saying PowerMocks (using the Mockito extension api) that we want to mock static methods in Customer class.

Next up, we have to stub the method we are interested in (we will be doing state based testing.  PowerMocks also supports interaction based testing, using the verify syntax.  Will not be showing it in this post though).  That's done like this

And then we can simply assert the customer is returned in the modelMap.  That's all!  Here's the complete test case code.

And we are done!  As we can see, PowerMocks (using the Mockito extension api) uses English like syntax, because of this test cases look a lot compact and are easier to read.

As usual, feedback, comments and complaints are always welcome!