Develop Reference

Mockito asks to add #PrepareForTest for the class even after adding #PrepareForTest

I have the following simple code. I have a class (TestClass) and I want to test "someMethod". There is an external static method which is called by my "someMethod".
I want to Powermock that static method to return me some dummy object.
I have the #PrepareForTest(ExternalClass.class) in the begining, but when I execute it gives the error:
The class ExternalClass not prepared for test.
To prepare this class, add class to the '#PrepareForTest' annotation.
In case if you don't use this annotation, add the annotation on class or method level.
Please help me to point out what is wrong with the way I have used #PrepareForTest
#RunWith(PowerMockRunner.class)
#PrepareForTest(ExternalClass.class)
public class xyzTest {
#Mock
private RestTemplate restTemplate;
#Mock
private TestClass testClass;
#BeforeClass
private void setUpBeforeClass() {
MockitoAnnotations.initMocks(this);
}
#Test
public void testSuccessCase() {
Boolean mockResponse = true;
ResponseEntity<Boolean> response = new ResponseEntity<Boolean>(mockResponse, HttpStatus.OK);
SomeClass someClass = new SomeClass("test", "1.0.0", "someUrl", "someMetaData");
PowerMockito.mockStatic(ExternalClass.class);
Mockito.when(restTemplate.postForEntity(any(String.class), any(String.class), eq(Boolean.class))).thenReturn(response);
Mockito.when(ExternalClass.getSomeClass(any(String.class))).thenReturn(someClass);
Boolean result = testClass.someMethod("test");
Assert.isTrue(result);
Mockito.verify(restTemplate, times(1)).postForObject(any(String.class), any(String.class), any());
}
}

Make sure you add #RunWith(PowerMockRunner.class) to the top of your class as well.
::edit:: two years later...
Don't ever use PowerMockito, you shouldn't need to.
If you do need to, you have most likely broken the SOLID principles and your design is wrong.
Fix your design instead.

As with the last answer, my problem was also mixing the Test annotation from TestNG instead of Junit Test.
import org.junit.Test; // works
import org.testng.annotations.Test // did not work
Very abstruse error and I spent more than 5 hrs debugging :(

For those trying to get this working with Junit 5, If your using the powermock-module-junit4 beta release which claims to be compatible with 4+, the library will still not recognize:
import org.junit.jupiter.api.Test;
and it will throw a:
org.powermock.api.mockito.ClassNotPreparedException
when #PrepareForTest is applied on the class you want to static mock. If you want to use PowerMock, you will have to go back to Junit 4 or create a MockWrapper for your static method at this time.
PowerMock 2.0: Github Roadmap

While the top-rated answer here is correct without a doubt, this does not answer the question of why is that needed; or, for example, why the same thing would not work with adding #RunWith(MockitoJUnitRunner.class).
The thing is PowerMockRunner uses instrumentation API under the hood, via
javassist library, this allows to alter the classes, like remove final or mock static (non-compile time constants).
In the process of modifying (instrumenting) a certain class, they add an interface to that, called PowerMockModified. It is a marker interface that denotes that a certain byte-code instrumentation took place. Later in the code, they simply check if the class that you use in #PrepareForTest was actually instrumented in some way or not, via such a method:
private boolean isModifiedByPowerMock() {
return PowerMockModified.class.isAssignableFrom(this.type);
}
In turns out that PowerMockRunner does some instrumentation, while MockitoJUnitRunner does not; thus the error you get.

I had the same error, resolved this by adding
#Rule
public PowerMockRule rule = new PowerMockRule();
inside the test class.

If above answers don't work try extends PowerMockTestCase. This trick worked for me.
Example:
public class xyzTest extends PowerMockTestCase

check if import org.junit.Test; package has imported and not that api jupiter one.

I had the same error but resolved it. My problem was that I included powermock-module-junit4 but included my test annotation from TestNG instead of Junit.

I had the same error. I was using TestNG to run the tests. I had to use the following method to fix the above issue.
#ObjectFactory
public IObjectFactory getObjectFactory() {
return new PowerMockObjectFactory();
}

For testNG there are 2 options as follows :
Using ObjectFactory as below:
#ObjectFactory
public IObjectFactory getObjectFactory() {
return new PowerMockObjectFactory();
}
Test class extending extends org.powermock.modules.testng.PowerMockTestCase

My gradle was using Junit 5.
test {
useJUnitPlatform()
}
I was able to debug this. By having breakpoints in PowerMockRunner methods.
It was not invoked. Moreover JUnit 5 is not supported with PowerMockito.
Looks like JUnit5 runs without #ExtendWith.

Make sure you are using powermock2. I had this problem when I was using powermock.
Use
import org.powermock2.api.mockito.PowerMockito;

How to set environment variable or system property in spring tests?

I'd like to write some tests that check the XML Spring configuration of a deployed WAR. Unfortunately some beans require that some environment variables or system properties are set. How can I set an environment variable before the spring beans are initialized when using the convenient test style with #ContextConfiguration?
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = "classpath:whereever/context.xml")
public class TestWarSpringContext { ... }
If I configure the application context with annotations, I don't see a hook where I can do something before the spring context is initialized.

You can initialize the System property in a static initializer:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = "classpath:whereever/context.xml")
public class TestWarSpringContext {
static {
System.setProperty("myproperty", "foo");
}
}
The static initializer code will be executed before the spring application context is initialized.

The right way to do this, starting with Spring 4.1, is to use a #TestPropertySource annotation.
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = "classpath:whereever/context.xml")
#TestPropertySource(properties = {"myproperty = foo"})
public class TestWarSpringContext {
...
}
See #TestPropertySource in the Spring docs and Javadocs.

One can also use a test ApplicationContextInitializer to initialize a system property:
public class TestApplicationContextInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext>
{
#Override
public void initialize(ConfigurableApplicationContext applicationContext)
{
System.setProperty("myproperty", "value");
}
}
and then configure it on the test class in addition to the Spring context config file locations:
#ContextConfiguration(initializers = TestApplicationContextInitializer.class, locations = "classpath:whereever/context.xml", ...)
#RunWith(SpringJUnit4ClassRunner.class)
public class SomeTest
{
...
}
This way code duplication can be avoided if a certain system property should be set for all the unit tests.

All of the answers here currently only talk about the system properties which are different from the environment variables that are more complex to set, esp. for tests. Thankfully, below class can be used for that and the class docs has good examples
EnvironmentVariables.html
A quick example from the docs, modified to work with #SpringBootTest
#SpringBootTest
public class EnvironmentVariablesTest {
#ClassRule
public final EnvironmentVariables environmentVariables = new EnvironmentVariables().set("name", "value");
#Test
public void test() {
assertEquals("value", System.getenv("name"));
}
}

If you want your variables to be valid for all tests, you can have an application.properties file in your test resources directory (by default: src/test/resources) which will look something like this:
MYPROPERTY=foo
This will then be loaded and used unless you have definitions via #TestPropertySource or a similar method - the exact order in which properties are loaded can be found in the Spring documentation chapter 24. Externalized Configuration.

For springboot, here would be the simplest way to do it in my opinion use the #SpringBootTest annotation you can in java:
#SpringBootTest(
properties = { "spring.application.name=example", "ENV_VARIABLE=secret" }
)
public class ApplicationTest {
// Write your tests here
}
Or in kotlin you can do:
#SpringBootTest(
properties = ["spring.application.name=example", "ENV_VARIABLE=secret"]
)
internal class ApplicationKTest {
// Write your tests here
}
And that's it your test should run overriding the properties with the one you have define in the annotation.
Let's say you had an application.yml looking like that:
spring:
application:
name: "app"
db:
username: "user"
password: ${ENV_VARIABLE:default}
Then during the test it would be:
The spring property spring.application.name will return the value "example"
The environment variable ENV_VARIABLE will return "secret", so if you use the value db.password in your code it would return "secret".

You can set the System properties as VM arguments.
If your project is a maven project then you can execute following command while running the test class:
mvn test -Dapp.url="https://stackoverflow.com"
Test class:
public class AppTest {
#Test
public void testUrl() {
System.out.println(System.getProperty("app.url"));
}
}
If you want to run individual test class or method in eclipse then :
1) Go to Run -> Run Configuration
2) On left side select your Test class under the Junit section.
3) do the following :

For Unit Tests, the System variable is not instantiated yet when I do "mvn clean install" because there is no server running the application. So in order to set the System properties, I need to do it in pom.xml. Like so:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<systemPropertyVariables>
<propertyName>propertyValue</propertyName>
<MY_ENV_VAR>newValue</MY_ENV_VAR>
<ENV_TARGET>olqa</ENV_TARGET>
<buildDirectory>${project.build.directory}</buildDirectory>
</systemPropertyVariables>
</configuration>
</plugin>

If you have a lot of test classes (IT tests that startup tomcat/server), and the tests are failing, you need to set the system property using
System.setProperty("ccm.configs.dir", configPath);
Since you need to make sure that is set before spring starts, you need to put it in a static context in a class.
And to make sure any test that may depend on it gets this set system property, define a simple config class in your test folder setting up that variable. P.S in my case the env variable that was needed was "ccm.configs.dir"
Here is what i added in my test folder,
#Configuration
public class ConfigLoader {
static {
System.setProperty("ccm.configs.dir", "path/to/the/resource");
}
}
And all my integration test classes were able to get that variable already set by the time they are run.

#Jimmy Praet's modified answer for JUnit5:
#ExtendWith(SpringExtension.class)
#ContextConfiguration(locations = "classpath:whereever/context.xml")
public class TestWarSpringContext {
#BeforeAll
static void initAll() {
System.setProperty("myproperty", "foo");
}
#AfterAll
static void tearDownAll() {
System.clearProperty("myproperty");
}
...
}

All the answers are grouped in two:
pass the env variables one by one using some annotation or System.setProperty;
to have another application.properties *yml
Both approaches work but based in several projects, to maintain 2 properties files and/or to pass all the properties in the string properties = {"myproperty = foo"} on each test will be a complicated
This worked for me:
Keep just one application.properties
Use env variables in the application.properties
truestore.custom.location = ${JRE_CACERT_LOCATION}
truestore.custom.password = ${JRE_CACERT_PASSWORD}
In the test that requires the application.properties like #WebMvcTest(FooController.class) and at the same time the env vars declares on application.properties add this code:
import static org.junit.jupiter.api.Assertions.assertEquals;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.stream.Stream;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.MvcResult;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import com.jayway.jsonpath.JsonPath;
#WebMvcTest(HealthController.class)
public class HealthControllerTest {
static {
File resourcesDirectory = new File("src/test/resources");
try (Stream<String> stream = Files.lines(
Paths.get(resourcesDirectory.getAbsolutePath() + File.separator + "application.env"))) {
stream.forEach(rawLine -> {
String pair[] = rawLine.trim().split("=");
System.setProperty(pair[0], pair[1]);
});
} catch (IOException e) {
e.printStackTrace();
}
}
}
create just one file with env variables required for all the tests: /src/test/resources/application.env
JRE_CACERT_LOCATION=/foo/bar/jre/cacert
JRE_CACERT_PASSWORD=changeme
Dependencies
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.5.0</version>
<relativePath />
</parent>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
Advantages
devops compatible
run on every shell
that file could be used for the developer to configure his Eclipse or Intellij
useful to configure manually the application in the server or with some configuration manager

Cannot run single unit test with JUnit and Eclipse for data-driven testing

I've stripped the problem from all unnecessary complexity and attached two files for clarity's sake. In actuality, I want to load the required input for testing from a database. In the example I have the suites map in the Suites class, instead of the result from the query. I also have a rather complex comparison instead of the simple one in the run method of TestOverride. Basically that's how I solved creating test suites with their tests from the database (suites map) in a dynamic way. In addition, it is important that I can see the test name when I run it with eclipse.
If you run Suites (just right click on it and JUnit-run on eclipse) it works fine. The only test that passes is test4. However, I would like to be able to run a single test with this type of construct (a single suite would be nice as well, but I would be happy with a single test). In other words, after running all suites, I would like to go to the JUnit window, right click on a single test and run it. If I do it it doesn't work. I somehow thought the tests were stored somewhere after the first run and that I could use them later.
I am using eclipse 3.6 and JUnit 4.0
Any ideas? I don't use annotations for parametrized classes because everything has to be known before compile time (and I take the input from a database). I've also seen in the forums that it's quite a problem renaming the test cases with that approach.
import java.util.HashMap;
import java.util.Map;
import junit.framework.Test;
import junit.framework.TestSuite;
public class Suites {
public static Test suite() {
Map<String, String[]> suites = new HashMap<String, String[]>();
suites.put("suite1", new String[]{"test1", "test2"});
suites.put("suite2", new String[]{"test3", "test4"});
TestSuite all = new TestSuite("All Suites");
for(Map.Entry<String, String[]> entry : suites.entrySet()) {
TestSuite suite = new TestSuite(entry.getKey());
for(String testName : entry.getValue()) {
suite.addTest(
new TestOverride(
testName
)
);
}
all.addTest(suite);
}
return all;
}
}
import junit.framework.AssertionFailedError;
import junit.framework.TestCase;
import junit.framework.TestResult;
public class TestOverride extends TestCase {
private String name;
public TestOverride(
String name)
{
this.name = name;
}
#Override
public void run(TestResult result) {
result.startTest(this);
if (this.name.equals("test4")) {
result.endTest(this);
} else {
result.addFailure(this, new AssertionFailedError("Not test4"));
}
}
#Override
public String getName() {
return name;
}
}

I don't think it is possible to achieve what you'd like. As far as I know (and experienced) only "real" junit-methods (that are actual methods in existing classes) can be executed from the junit window (this is easily reproduced when using parameterized tests. The specific Tests can't be run here again either).
Perhaps you should try to generate the java code for the tests(and compile it).

It's much easier if you override runTest() and create the TestSuite from your TestCase class.
Here is an example that works:
http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html

How to JMockIt System.getenv(String)?

What I have right now
I have a 3rd party singleton instance that my class under test relies on and that singleton is using System.getenv(String) in its constructor. Is it possible to mock this call?
I tried this
JMockIt Example
new Expectations()
{
System mockedSystem;
{
System.getenv( "FISSK_CONFIG_HOME" ); returns( "." );
}
};
But it gives me an EXCEPTION_ACCESS_VIOLATION and crashes the JVM.
Is there another way to set a system environment variable for a unit test?

In this case you need to use partial mocking so that JMockit doesn't redefine everything in the System class. The following test will pass:
#Test
public void mockSystemGetenvMethod()
{
new Expectations()
{
#Mocked("getenv") System mockedSystem;
{
System.getenv("envVar"); returns(".");
}
};
assertEquals(".", System.getenv("envVar"));
}
I will soon implement an enhancement so that issues like this don't occur when mocking JRE classes. It should be available in release 0.992 or 0.993.

PowerMock seams to be able to mock system classes.
Your other option (assuming you are not unit testing the 3rd party API) is to create a for Facade the 3rd party API that has a nice, easy mockable interface and have your test classes use this rather than the real thing.
Oh, JMockIt supports this too:
package playtest;
import static org.junit.Assert.*;
import mockit.*;
import mockit.integration.junit4.JMockit;
import org.junit.*;
import org.junit.runner.RunWith;
#RunWith(JMockit.class)
public class JMockItTest {
#Test
public void mockSystemGetEnv() {
Mockit.setUpMocks(MockSystem.class);
assertEquals("Bye", System.getenv("Hello"));
}
#MockClass(realClass = System.class)
public static class MockSystem {
#Mock
public static String getenv(String str) {
return "Bye";
}
}
}

You can't change the environment but you can change the access to it: Simply wrap the call to System.getenv() in a method or a helper class and then mock that.
[EDIT] Now your problem is how to change the code of your third party library. The solution here is to use a Java decompiler and to fix the class. If you want, you can send in a feature request in, too. Add that new class to your test suite. That should make your IDE find the class for the tests.
Since test code doesn't go into production, you can run your tests and the production code will use the original library.

A while back I wanted to test System.exit, and found a solution by using a custom SecurityManager. You can verify the call is being made, and the argument of the call, but using this method, you can't mock the return value of the call.

An update on #Rogério answer.
In my case with JMockit 1.25 I had to do it using the MockUp API:
#Test
public void mockSystemGetenvMethod(){
new MockUp<System>()
{
#Mock
public String getenv(final String string) {
return "";
}
};
assertEquals(".", System.getenv("envVar"));
}

Grouping JUnit tests

Is there any way to group tests in JUnit, so that I can run only some groups?
Or is it possible to annotate some tests and then globally disable them?
I'm using JUnit 4, I can't use TestNG.
edit: #RunWith and #SuiteClasses works great. But is it possible to annotate like this only some tests in test class? Or do I have to annotate whole test class?

JUnit 4.8 supports grouping:
public interface SlowTests {}
public interface IntegrationTests extends SlowTests {}
public interface PerformanceTests extends SlowTests {}
And then...
public class AccountTest {
#Test
#Category(IntegrationTests.class)
public void thisTestWillTakeSomeTime() {
...
}
#Test
#Category(IntegrationTests.class)
public void thisTestWillTakeEvenLonger() {
...
}
#Test
public void thisOneIsRealFast() {
...
}
}
And lastly,
#RunWith(Categories.class)
#ExcludeCategory(SlowTests.class)
#SuiteClasses( { AccountTest.class, ClientTest.class })
public class UnitTestSuite {}
Taken from here: https://community.oracle.com/blogs/johnsmart/2010/04/25/grouping-tests-using-junit-categories-0
Also, Arquillian itself supports grouping:
https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/Categories.java

Do you want to group tests inside a test class or do you want to group test classes? I am going to assume the latter.
It depends on how you are running your tests. If you run them by Maven, it is possible to specify exactly what tests you want to include. See the Maven surefire documentation for this.
More generally, though, what I do is that I have a tree of test suites. A test suite in JUnit 4 looks something like:
#RunWith(Suite.class)
#SuiteClasses({SomeUnitTest1.class, SomeUnitTest2.class})
public class UnitTestsSuite {
}
So, maybe I have a FunctionTestsSuite and a UnitTestsSuite, and then an AllTestsSuite which includes the other two. If you run them in Eclipse you get a very nice hierarchical view.
The problem with this approach is that it's kind of tedious if you want to slice tests in more than one different way. But it's still possible (you can for example have one set of suites that slice based on module, then another slicing on the type of test).

To handle the globally disabling them, JUnit (4.5+) has two ways One is to use the new method assumeThat. If you put that in the #BeforeClass (or the #Before) of a test class, and if the condition fails, it will ignore the test. In the condition you can put a system property or something else that can be globally set on or off.
The other alternative is to create a custom runner which understands the global property and delegates to the appropriate runner. This approach is a lot more brittle (since the JUnit4 internal runners are unstable and can be changed from release to release), but it has the advantage of being able to be inherited down a class hierarchy and be overridden in a subclass. It is also the only realistic way to do this if you have to support legacy JUnit38 classes.
Here is some code to do the custom Runner. Regarding what getAppropriateRunnerForClass might do, the way I implemented it was to have a separate annotation that tells the custom runner what to run with. The only alternative was some very brittle copy paste from the JUnit code.
private class CustomRunner implements Runner
private Runner runner;
public CustomRunner(Class<?> klass, RunnerBuilder builder) throws Throwable {
if (!isRunCustomTests()) {
runner = new IgnoredClassRunner(klass);
} else {
runner = getAppropriateRunnerForClass(klass, builder);
}
public Description getDescription() {
return runner.getDescription();
}
public void run(RunNotifier notifier) {
runner.run(notifier);
}
}
EDIT: The #RunWith tag only works for a whole class. One way to work around that limiation is to move the test methods into a static inner class and annotate that. That way you have the advantage of the annotation with the organization of the class. But, doing that won't help with any #Before or #BeforeClass tags, you will have to recreate those in the inner class. It can call the outer class's method, but it would have to have its own method as a hook.

In JUnit 5 you can declare #Tag for filtering tests, either at the class or method level; analogous to test groups in TestNG or Categories in JUnit 4
From the javadoc :
tags are used to filter which tests are executed for a given test
plan. For example, a development team may tag tests with values such
as "fast", "slow", "ci-server", etc. and then supply a list of tags to
be used for the current test plan, potentially dependent on the
current environment.
For example you could declare a test class with a "slow" #Tag that will be inherited for all methods and override it for some methods if required :
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
#Tag("slow")
public class FooTest{
//
#Test
void loadManyThings(){
...
}
#Test
void loadManyManyThings(){
...
}
#Test
#Tag("fast")
void loadFewThings(){
...
}
}
You could apply the same logic for other test classes.
In this way test classes (and methods too) belongs to a specific tag.
As a good practice instead of copying and pasting #Tag("fast") and #Tag("slow") throughout the test classes, you can create custom composed annotations.
For example :
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.junit.jupiter.api.Tag;
#Target({ ElementType.TYPE, ElementType.METHOD })
#Retention(RetentionPolicy.RUNTIME)
#Tag("slow")
public #interface Slow {
}
and use it as :
#Test
#Slow
void slowProcessing(){
...
}
To enable or disable test marked with a specific tag during the text execution you can rely on the maven-surefire-plugin documentation :
To include tags or tag expressions, use groups.
To exclude tags or tag expressions, use either excludedGroups.
Just configure in your pom.xml the plugin according to your requirement (example of the doc) :
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.0</version>
<configuration>
<groups>acceptance | !feature-a</groups>
<excludedGroups>integration, regression</excludedGroups>
</configuration>
</plugin>
</plugins>
</build>
For information the test goal documentation is not updated.

Try JUnit Test Groups. From documentation :
#TestGroup("integration")
public class MyIntegrationTest {
#ClassRule
public static TestGroupRule rule = new TestGroupRule();
...
}
Execute a simple test group: -Dtestgroup=integration
Execute multiple test groups: -Dtestgroup=group1,group2
Execute all test groups: -Dtestgroup=all

You can create test Suite objects that contain groups of tests. Alternatively, your IDE (like Eclipse) may have support for running all the tests contained in a given package.

You can Use Test Suite(http://qaautomated.blogspot.in/2016/09/junit-test-suits-and-test-execution.html) or you can Junit Categories(http://qaautomated.blogspot.in/2016/09/junit-categories.html) for grouping your test cases effectively.