PowerMock Setup

JAR's

The following JAR's need to be included in your Java project's buildpath in order for PowerMock to work properly with JUnit tests.

Download link: https://github.com/jayway/powermock/wiki/Downloads
  1. powermock-api-mockito-common-1.6.5.jar
  2. objenesis-2.2.jar
  3. powermock-mockito-1.6.5-full.jar
  4. mockito-core-1.10.19.jar
  5. javassist-3.20.0-GA.jar
  6. hamcrest-core-1.3.jar
  7. junit-4.12.jar

JUnit test class

The following lines of code need to be included in JUnit test classes to add PowerMock functionality. 
 
1|    import org.powermock.core.classloader.annotations.PrepareForTest;
2|    import org.powermock.modules.junit4.PowerMockRunner;
3|
4|    @PrepareForTest(ChildClass.class)
5|    @RunWith(PowerMockRunner.class)
6|    public class ClassTest {
7|    ...
8|    }

In most cases the class under test needs to be included as a parameter in the @PrepareForTest annotation. PowerMockRunner.class must always be included within the @RunWith annotation when using PowerMock, unless a custom Test Runner is needed.

Comments

Post a Comment

Popular posts from this blog

Mocking Super Class Method Invocations with PowerMock

Mocking Superclass Method Invocations with PowerMock Code Example See the setup page to learn more about setting up PowerMock. There may be situations when you are forced to call a super class method when overriding. For instance, in Android development, one must constantly interact with the life cycle call back methods. However, when running unit tests on these methods, exceptions are thrown due to Android system dependency interactions in super class method calls (unit tests are run locally on the developer's machine). Therefore, mocking the super class method invocations are crucial towards running successful unit tests. SuperClass.java 1| package main; 2| public class SuperClass { 3| public void foo() { 4| System.out.println("Super Class!"); 5| } 6| } ChildClass.java 1| package main; 2| public class ChildClass extends SuperClass { 3| @Override 4| public void foo() { 5| super.foo()...
Keep reading

Verifying Static Method Calls

This section explains how to verify mocked static method calls, and why it's important to include them within unit tests. Code Example There may be cases where some code you want to test interacts with an external system, such as a database for example. You wouldn't want to execute the SQL statements within a unit test, especially if the query takes some time. However, we may want to ensure that the mocked DAO is invoked. This can easily be handled with Mockito, but what if the SQL statement is within a static method? That's where verify comes in handy with PowerMock. Below is an example of such a scenario. UnderTest.java 1| package main; 2| 3| public class UnderTest { 4| public void foo() { 5| DAO.executeSQL(); 6| } 7| } Method under test foo() that invokes the SQL statement. DAO.java 1| package main; 2| 3| public class DAO { 4| public static void executeSQL() { 5| System.out.println("Exec...
Keep reading

Unit Testing a Singleton Using PowerMock

I came across an interesting problem this week at work. I had to make some changes to a Singleton class in Java, and had some issues when trying to unit test the changes. When JUnit runs each test method with the @Test annotation, a new object of the test class is instantiated, this ensures that there are no side effects between test cases. However, the Singleton class that is under test returns a reference to it's object upon each invocation of it static factory method. This can be a problem for your test cases because they are referencing the same object under test, opposed to a new one, which can cause side effects from previous tests. Luckily you can get around this issue using PowerMock. The code snippets below show how to do this yourself... Code Example SingletonTest.java 1| package test; 2| 3| import static org.junit.Assert.fail; 4| import main.Singleton; 5| 6| import org.junit.Before; 7| import org.junit.Test; 8| import org.junit.runn...
Keep reading