How to use startTest method of junit.runner.BaseTestRunner class

Yes, you can. I was doing it couple of times to run diagnostic/smoke tests in production systems. This is a snippet of key part of the code invoking JUnit:

JUnitCore junit = new JUnitCore();
Result result = junit.run(testClasses);

DON'T use JUnit.main inside your application, it invokes System.exit after tests are finished and thus it may stop JVM process.

You may want to capture JUnit's "regular" console output (the dots and simple report). This can be easily done by registering TextListener (this class provides this simple report).

Please also be aware of several complications using this kind of method:

1. Testing of any "test framework", including so small one, although is quite simple may be confusing. For example if you want to test if your "test framework" return failure result when one of the tests fails you could (should?) create sample JUnit test that always fails and execute that test with the "test framework". In this case failing test case is actually test data and shouldn't be executed as "normal" JUnit. For an example of such tests you can refer to JUnit's internal test cases.

2. If you want to prepare / display your custom report you should rather register your own RunListener, because Result returned by JUnit doesn't contain (directly) information about passed tests and test method (it is only "hardcoded" as a part of test Description).

According to the Mockito documentation you can set different behavior for consecutive method calls.

when(mock.someMethod("some arg"))
    .thenThrow(new RuntimeException())
    .thenReturn("foo");

In case of a void method you can do something similar (Mockito documentation)

doThrow(new RuntimeException())
    .doNothing()
    .when(mock).doSomething();

The orthodox thing to do here would be to change you code so that the Context is injected into it (by a dependency injection framework, or manually). Then, you simply pass in a mock in your unit test.

If you can't do this, and your code must create the IntialContext itself, then you will need to set up a fake JNDI implementation into which you can inject mocks. If you search the web for in-memory JNDI implementation or mock JNDI implementation, you will find various options, or you could write one yourself. Basically, you will need an implementation of InitialContextFactory which simply returns a suitable mock, which you then select by setting the java.naming.factory.initial system property.

I had a crack at writing the necessary classes. Here you go:

public class MockInitialContextFactory implements InitialContextFactory {

    private static final ThreadLocal<Context> currentContext = new ThreadLocal<Context>();

    @Override
    public Context getInitialContext(Hashtable<?, ?> environment) throws NamingException {
        return currentContext.get();
    }

    public static void setCurrentContext(Context context) {
        currentContext.set(context);
    }

    public static void clearCurrentContext() {
        currentContext.remove();
    }

}

public class MockInitialContextRule implements TestRule {

    private final Context context;

    public MockInitialContextRule(Context context) {
        this.context = context;
    }

    @Override
    public Statement apply(final Statement base, Description description) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                System.setProperty(Context.INITIAL_CONTEXT_FACTORY, MockInitialContextFactory.class.getName());
                MockInitialContextFactory.setCurrentContext(context);
                try {
                    base.evaluate();
                } finally {
                    System.clearProperty(Context.INITIAL_CONTEXT_FACTORY);
                    MockInitialContextFactory.clearCurrentContext();
                }
            }
        };
    }
}

Use as follows:

public class FooTest {

    private final Context context = mock(Context.class);

    @Rule
    public MockInitialContextRule mockInitialContextRule = new MockInitialContextRule(context);

    @Test
    public void testName() throws Exception {
        // set up stubbings on the context mock
        // invoke the code under test
    }
}

You should use RuntimeException or subclass it. Your method has to declare checked exception (example: findByState(String state) throws IOException;) otherwise use RuntimeException:

 when(userRepository.findByState("Karnataka"))
       .thenThrow(new RuntimeException("Exception"));

The JUnit way is to do this at run-time is org.junit.Assume.

 @Before
 public void beforeMethod() {
     org.junit.Assume.assumeTrue(someCondition());
     // rest of setup.
 }

You can do it in a @Before method or in the test itself, but not in an @After method. If you do it in the test itself, your @Before method will get run. You can also do it within @BeforeClass to prevent class initialization.

An assumption failure causes the test to be ignored.

Edit: To compare with the @RunIf annotation from junit-ext, their sample code would look like this:

@Test
public void calculateTotalSalary() {
    assumeThat(Database.connect(), is(notNull()));
    //test code below.
}

Not to mention that it is much easier to capture and use the connection from the Database.connect() method this way.

The JUnit way to compose reusable code (instead of inheriting from it) are Rules.

See https://github.com/junit-team/junit/wiki/Rules

Here is a dumb sample, but you'll get the point.

import org.junit.rules.TestRule;
import org.junit.runners.model.Statement;
import org.junit.runner.Description;

public class MyTestRule implements TestRule {
  @Override
  public Statement apply(final Statement statement, Description description) {
    return new Statement() {
      public void evaluate() throws Throwable {
        // Here is BEFORE_CODE
        try {
          statement.evaluate();
        } finally {
          // Here is AFTER_CODE
        }
      }
    };
  }
}

You can then use your TestRule like this:

import org.junit.Rule;

public class MyTest {
    @Rule
    public MyTestRule myRule = new MyTestRule();
}

BEFORE_CODE and AFTER_CODE will then be executed around each of your test methods.

If you need to run your code only once per class, use your TestRule as a @ClassRule:

import org.junit.ClassRule;

public class MyTest {
    @ClassRule
    public static MyTestRule myRule = new MyTestRule();
}

Now, BEFORE_CODE and AFTER_CODE will be executed around each of your test class.

@Rule field is not static, @ClassRule field is.

A @ClassRule can be declared in a Suite too.

Note that you can declare several rules in a single test class, that's how you compose test lifecycles at test-suites, test-classes and test-methods levels.

A Rule is an object that you instanciate in your test classes (statically or not). You can add contructor parameters if needed.

HTH

You don't need to mess with class loaders. In fact it's a bad habit to get into because class loader resources are not java.io.File objects when they are in a jar archive.

Maven automatically sets the current working directory before running tests, so you can just use:

    File resourcesDirectory = new File("src/test/resources");

resourcesDirectory.getAbsolutePath() will return the correct value if that is what you really need.

I recommend creating a src/test/data directory if you want your tests to access data via the file system. This makes it clear what you're doing.

Probably, the versions of Powermock and Mockito are not compatible. Fix that and it won't be a n issue anymore.

Mockito                     PowerMock
1.10.8+                     1.6.2+
1.9.5-rc1 - 1.9.5           1.5.0 - 1.5.6
1.9.0-rc1 & 1.9.0           1.4.10 - 1.4.12
1.8.5                       1.3.9 to 1.4.9
1.8.4                       1.3.7 & 1.3.8 
1.8.3                       1.3.6
1.8.1 & 1.8.2               1.3.5
1.8                         1.3
1.7                         1.2.5

See: https://github.com/powermock/powermock/wiki/Mockito#supported-versions

From version 4.11 you can specify execution order using annotations and ordering by method name:

import org.junit.Test;
import org.junit.FixMethodOrder;
import org.junit.runners.MethodSorters;

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class MyTest {

    @Test
    public void test1Create() {
        System.out.println("first");
    }

    @Test
    public void test2Update() {
        System.out.println("second");
    }
}

See JUnit 4.11 Release Notes