How to set JVM parameters for Junit Unit Tests?

I have some Junit unit tests that require a large amount of heap-space to run - i.e. 1G. (They test memory-intensive functionality for a webstart app that will only run with sufficient heap-space, and will be run internally on Win 7 64-bit machines - so redesigning the tests isn't a practical suggestion.)

I am developing in Intellij IDEA, so I know I can set the JVM parameters (e.g. -Xmx1024M) for the test class. However, this is only for running the whole test class - if I want to run an individual test, I have to recreate the run congfigurations for that test method.

Also, those are IDE and box specific - so if I switch boxes (I develop on multiple machines) or one of my colleagues tries to run the tests, those settings are not transferred. (Also, other IDEs like Eclipse and NetBeans are used by my colleagues.) FWIW, we're using mercurial for source code control.

For the build cycle, we're using Maven, so I know how to specify the JVM parameters for that.

So: - I'm looking for a way of specifying the JVM parameters that will apply for the whole test class and the individual test methods; and - I'd like to share those specification across IDEs on any开发者_如何学JAVA machine (having picked up the code from the repository).

In Maven you can configure the surefire plugin

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.9</version>
    <configuration>
        <argLine>-Xmx256M</argLine>
    </configuration>
</plugin>

If you use Maven for builds then this configuration will be carried in the source tree and applied when tests are carried out. See the Maven Surefire Plugin documentation.

In IntelliJ you can specify default settings for each run configuration. In Run/Debug configuration dialog (the one you use to configure heap per test) click on Defaults and JUnit. These settings will be automatically applied to each new JUnit test configuration. I guess similar setting exists for Eclipse.

However there is no simple option to transfer such settings (at least in IntelliJ) across environments. You can commit IntelliJ project files to your repository: it might work, but I do not recommend it.

You know how to set these for maven-surefire-plugin. Good. This is the most portable way (see Ptomli's answer for an example).

For the rest - you must remember that JUnit test cases are just a bunch of Java classes, not a standalone program. It is up to the runner (let it be a standalone JUnit runner, your IDE, maven-surefire-plugin to set those options. That being said there is no "portable" way to set them, so that memory settings are applied irrespective to the runner.

To give you an example: you cannot define Xmx parameter when developing a servlet - it is up to the container to define that. You can't say: "this servlet should always be run with Xmx=1G.

Parameters can be set on the fly also.

mvn test -DargLine="-Dsystem.test.property=test"

See http://www.cowtowncoder.com/blog/archives/2010/04/entry_385.html

According to this support question https://intellij-support.jetbrains.com/hc/en-us/community/posts/206165789-JUnit-default-heap-size-overridden-

the -Xmx argument for an IntelliJ junit test run will come from the maven-surefire-plugin, if it's set.

This pom.xml snippet

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <argLine>-Xmx1024m</argLine>
            </configuration>
        </plugin>

seems to pass the -Xmx1024 argument to the junit test run, with IntelliJ 2016.2.4.

I agree with the others who said that there is no simple way to distribute these settings.

For Eclipse: ask your colleagues to set the following:

• Windows Preferences / Java / Installed JREs:
• Select the proper JRE/JDK (or do it for all of them)
• Edit
• Default VM arguments: -Xmx1024m
• Finish, OK.

After that all test will run with -Xmx1024m but unfortunately you have set it in every Eclipse installation. Maybe you could create a custom Eclipse package which contains this setting and give it to you co-workers.

The following working process also could help: If the IDE cannot run a test the developer should check that Maven could run this test or not.

• If Maven could run it the cause of the failure usually is the settings of the developer's IDE. The developer should check these settings.
• If Maven also could not run the test the developer knows that the cause of the failure is not the IDE, so he/she could use the IDE to debug the test.

You can use systemPropertyVariables (java.protocol.handler.pkgs is your JVM argument name):

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12.4</version>
    <configuration>
        <systemPropertyVariables>
            <java.protocol.handler.pkgs>com.zunix.base</java.protocol.handler.pkgs>
            <log4j.configuration>log4j-core.properties</log4j.configuration>
        </systemPropertyVariables>
    </configuration>
</plugin>

http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html

If you set it in Java code, you can set it like this

      static {
        System.getProperties().setProperty("env", "test");
        System.getProperties().setProperty("spring.application.name", "spring-example");
    }

reference：

https://stackoverflow.com/a/60654275/4712855

https://stackoverflow.com/a/10774432/4712855

An eclipse specific alternative limited to the java.library.path JVM parameter allows to set it for a specific source folder rather than for the whole jdk as proposed in another response:

1. select the source folder in which the program to start resides (usually source/test/java)
2. type alt enter to open Properties page for that folder
3. select native in the left panel
4. Edit the native path. The path can be absolute or relative to the workspace, the second being more change resilient.

For those interested on detail on why maven argline tag should be preferred to the systemProperties one, look, for example:

Pick up native JNI files in Maven test (lwjgl)