From the top of my head I can think of 2 options:

Option1: Do what @Ethan said, it'll likely work:

package placeholder;

//your imports

public class Application{
  static {
      System.getProperties().set("javafx.embed.singleThread", "true");  
  }
  // your code
  public static void main(String... args){
    //your code
  }
}

Option 2: Use the application plugin + default jvm values

build.gradle:

apply plugin: 'application'
//your code
applicationDefaultJvmArgs = ["-Djavafx.embed.singleThread=true"]

Now you can run your code 2 ways:

From gradle

$gradle run

From distribution(script). from the generated script that the application plugin will provide:

$gradle clean build distZip

Then gradle will generate a zip file somewhere under ${your.projectdir}/build. Find the zip then unzip it and under /bin you'll find a ${yourproject}.bat and ${yourproject} executables. One is for Linux/mac/unix (${yourproject}) the other one is for windows (${yourproject.bat})

Option 3 (Android Developer): Use gradle.properties to set jvm argument

# Project-wide Gradle settings.

# IDE (e.g. Android Studio) users:
# Gradle settings configured through the IDE *will override*
# any settings specified in this file.

# For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html

# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx1024m -XX:MaxPermSize=256m
# org.gradle.jvmargs=-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 

# You can setup or customize it according to your needs and combined with the above default value.
org.gradle.jvmargs=-Djavafx.embed.singleThread=true

For more info on how to use gradle build environment on docs.gradle.org

Add hamcrest-all-X.X.jar to your classpath.

Latest version as of Feb 2015 is 1.3: http://code.google.com/p/hamcrest/downloads/detail?name=hamcrest-all-1.3.jar&can=2&q=

The right thing to do is to restructure your code to make it more testable as shown below. Restructuring your code to remove the direct dependency on Date will allow you to inject different implementations for normal runtime and test runtime:

interface DateTime {
    Date getDate();
}

class DateTimeImpl implements DateTime {
    @Override
    public Date getDate() {
       return new Date();
    }
}

class MyClass {

    private final DateTime dateTime;
    // inject your Mock DateTime when testing other wise inject DateTimeImpl

    public MyClass(final DateTime dateTime) {
        this.dateTime = dateTime;
    }

    public long getDoubleTime(){
        return dateTime.getDate().getTime()*2;
    }
}

public class MyClassTest {
    private MyClass myClassTest;

    @Before
    public void setUp() {
        final Date date = Mockito.mock(Date.class);
        Mockito.when(date.getTime()).thenReturn(30L);

        final DateTime dt = Mockito.mock(DateTime.class);
        Mockito.when(dt.getDate()).thenReturn(date);

        myClassTest = new MyClass(dt);
    }

    @Test
    public void someTest() {
        final long doubleTime = myClassTest.getDoubleTime();
        assertEquals(60, doubleTime);
    }
}

Since Android Studio 1.1, there is (experimental) unit test support. A couple of quotes from that page:

You will have to specify your testing dependencies in the build.gradle file of your android module. For example:

dependencies {
  testCompile 'junit:junit:4.12'
  testCompile "org.mockito:mockito-core:1.9.5"
}

To use unit testing support in AS, you have to do the following steps:

1. Update build.gradle to use the android gradle plugin version 1.1.0-rc1 or later (either manually in build.gradle file or in the UI in File > Project Structure)

2. Add necessary testing dependencies to app/build.gradle (see above).

3. Enable the unit testing feature in Settings > Gradle > Experimental.

4. Sync your project.

5. Open the "Build variants" tool window (on the left) and change the test artifact to "Unit tests".

6. Create a directory for your testing source code, i.e. src/test/java. You can do this from the command line or using the Project view in the Project tool window. The new directory should be highlighted in green at this point. Note: names of the test source directories are determined by the gradle plugin based on a convention.

7. Create your test. You can do this by opening a class, right-clicking its name and selecting "Go to > Test". Add some test cases.
8. Right click your new test class or method and select "Run ...".
9. (Optional) You can decrease the compilation time by using Gradle directly. To do this, go to the Run menu and select "Edit configurations". There, find the default JUnit template, remove the "Make" before-launch step and add a "Gradle aware make" step instead (leave the task name empty).

It is important to know that there are two test types: androidTest and plain test.

• androidTest is primarily for tests you run on an emulator or device, such as instrumentation tests. From the command line, you use ./gradlew connectedCheck to run these.
• test is for tests you don't want to run on a device, such as the unit test you wrote. You run ./gradlew test to run these tests.

As stated in the quote, you switch between androidTest and test in Android Studio by changing the test artifact.

Naturally, it is preferred to not run tests on a device or emulator, since this speeds up the testing process a lot. With the new experimental unit test support, you gain access to stubbed Android API's without using a device. This lets you move more tests from androidTest to test.

1. Consider using ExpectedException instead of @Test(expected.... This is because if for example you expect a NullPointerException and your test throws this exception in your setup (before calling the method under test) your test will pass. With ExpectedException you put the expect immediately before the call to the method under test so there is no chance of this. Also, ExpectedException allows you to test the exception message which is helpful if you have two different IllegalArgumentExceptions that might be thrown and you need to check for the correct one.

2. Consider isolating your method under test from the setup and verify, this will ease in test review and maintenance. This is especially true when methods on the class under test are invoked as part of setup which can confuse which is the method under test. I use the following format:

   public void test() {
      //setup
      ...
   
      // test (usually only one line of code in this block)
      ...
   
      //verify
      ...
   }
   

3. Books to look at: Clean Code, JUnit In Action, Test Driven Development By Example

   Clean Code has an excellent section on testing

4. Most example I have seen (including what Eclipse autogenerates) have the method under test in the title of the test. This facilitates review and maintenance. For example: testOfComponents_nullCase. Your example is the first I have seen that uses the Enclosed to group methods by method under test, which is really nice. However, it adds some overhead as @Before and @After do not get shared between enclosed test classes.

5. I have not started using it, but Guava has a test library: guava-testlib. I have not had a chance to play with it but it seems to have some cool stuff. For example: NullPointerTest is quote:

• A test utility that verifies that your methods throw {@link * NullPointerException} or {@link UnsupportedOperationException} whenever any * of their parameters are null. To use it, you must first provide valid default * values for the parameter types used by the class.

Review: I realize the test above was just an example but since a constructive review might be helpful, here you go.

1. In testing getComponents, test the empty list case as well. Also, use IsIterableContainingInOrder.

2. In testing of ofComponents, it seems that it would make sense to call getComponents or toString to validate that it properly handled the various non-error cases. There should be a test where no argument is passed to ofComponents. I see that this is done with ofComponents( new String[]{}) but why not just do ofComponents()? Need a test where null is one of the values passed: ofComponents("blah", null, "blah2") since this will throw an NPE.

3. In testing ROOT, as has been pointed out before, I suggest calling ROOT.getComponents once and doing all three verifications on it. Also, ItIterableContainingInOrder does all three of not empty, size and contains. The is in the tests is extraineous (although it is linguistic) and I feel is not worth having (IMHO).

4. In testing toString, I feel it is very helpful to isolate the method under test. I would have written toStringIsSlashSeparatedPathOfComponents as follows. Notice that I do not use the constant from the class under test. This is because IMHO, ANY functional change to the class under test should cause the test to fail.

   @Test     
   public void toStringIsSlashSeparatedPathOfComponents() {       
      //setup 
      String[] components = { "Test1", "Test2", "Test3" };       
      String expectedPath =  "/" + Joiner.on("/").join(components);   
      MyPath path = MyPath.ofComponents(components)
   
      // test
      String value = path.toStrign();
   
      // verify
      assertThat(value, equalTo(expectedPath));   
   } 
   

5. Enclosed will not run any unit test that is not in an inner class. Therefore testPathCreationFromComponents would not be run.

Finally, use Test Driven Development. This will ensure that your tests are passing for the right reason and will fail as expected.

If possible I would try to write those test without Spring Context. If you create this class in your test without spring, then you have full control over its fields.

To set the @value field you can use Springs ReflectionTestUtils - it has a method setField to set private fields.

@see JavaDoc: ReflectionTestUtils.setField(java.lang.Object, java.lang.String, java.lang.Object)

The takari-cpsuite (originally developed by Johannes Link) offers a classpath-suite which should fit your needs. It allows filtering of classes in the Classpath by regular expressions like:

import org.junit.extensions.cpsuite.ClasspathSuite.*;
...
@ClassnameFilters({"mytests.*", ".*Test"})
public class MySuite...

JaCoCo offers that feature.

JaCoCo with Configuration rules

Define JaCoCo plugin using configuration rules COVEREDRATIO forLINE and BRANCH :

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.7.7.201606060606</version>
  <executions>
    <execution>
      <id>default-prepare-agent</id>
      <goals>
        <goal>prepare-agent</goal>
      </goals>
    </execution>
    <execution>
      <id>check</id>
      <goals>
          <goal>check</goal>
      </goals>
      <configuration>
        <rules>
          <rule>
            <element>CLASS</element>
            <limits>
              <limit>
                <counter>LINE</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.80</minimum>
              </limit>
              <limit>
                <counter>BRANCH</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.80</minimum>
              </limit>
            </limits>
            <excludes>
              <exclude>com.xyz.ClassToExclude</exclude>
            </excludes>
          </rule>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

Various options

The supported counter options are:

• LINE
• BRANCH
• INSTRUCTION
• COMPLEXITY
• METHOD
• CLASS

I believe INSTRUCTION would allow you to make a general check (verify that the whole project has at least 0.80 of coverage for instance).

Example with INSTRUCTION - overall instruction coverage of 80%

This example requires an overall instruction coverage of 80% and no class must be missed:

<rules>
  <rule implementation="org.jacoco.maven.RuleConfiguration">
    <element>BUNDLE</element>
    <limits>
      <limit implementation="org.jacoco.report.check.Limit">
        <counter>INSTRUCTION</counter>
        <value>COVEREDRATIO</value>
        <minimum>0.80</minimum>
      </limit>
      <limit implementation="org.jacoco.report.check.Limit">
        <counter>CLASS</counter>
        <value>MISSEDCOUNT</value>
        <maximum>0</maximum>
      </limit>
    </limits>
  </rule>
</rules>

Message on failure

If the coverage isn't as expected, it fails with the following message:

[WARNING] Rule violated for class com.sampleapp.SpringConfiguration: lines covered ratio is 0.00, but expected minimum is 0.80
[WARNING] Rule violated for class com.sampleapp.Launcher: lines covered ratio is 0.33, but expected minimum is 0.80
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Exclusions

In the example above, I set <exclude>com.xyz.ClassToExclude</exclude>. I think you'll find you need to add many exclusions. Projects usually contain many classes which aren't testable/tested (Spring Configuration, Java beans...). You may be able to use regular expression too.

sources:

• http://choudhury.com/blog/2014/02/25/enforcing-minimum-code-coverage
• http://www.eclemma.org/jacoco/trunk/doc/maven.html
• http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html

This is a bug that occurs when you use JUnit 4.12 and PowerMock < 1.6.1. The problem is solved in PowerMock 1.6.1. Please update your dependencies accordingly

testCompile 'junit:junit:4.12',
            'org.powermock:powermock-core:1.6.1',
            'org.powermock:powermock-module-junit4:1.6.1',
            'org.powermock:powermock-api-mockito:1.6.1'

If you cannot upgrade PowerMock then you can use JUnit 4.11.

testCompile 'junit:junit:4.11',
            'org.powermock:powermock-core:1.5.6',
            'org.powermock:powermock-module-junit4:1.5.6',
            'org.powermock:powermock-api-mockito:1.5.6'

Could you please add further lines of the stacktrace, which uncover more details about the problem.