How to use RunRules class of org.junit.rules package

You can use assertThrows(), which allows you to test multiple exceptions within the same test. With support for lambdas in Java 8, this is the canonical way to test for exceptions in JUnit.

Per the JUnit docs:

import static org.junit.jupiter.api.Assertions.assertThrows;

@Test
void exceptionTesting() {
    MyException thrown = assertThrows(
           MyException.class,
           () -> myObject.doThing(),
           "Expected doThing() to throw, but it didn't"
    );

    assertTrue(thrown.getMessage().contentEquals("Stuff"));
}

The actual behavior for JUnit 5 is expected as the @BeforeEach javadoc states :

Inheritance

@BeforeEach methods are inherited from superclasses as long as they are not overridden.

You override the setup() method that contains @BeforeEach in the InheritsFromBase class.
So it is not inherited any longer.

For JUnit 4, the @Before javadoc doesn't state any particularity and inheritance abilities.
So you should consider the actual behavior as "normal" but no documented.

To get the same behavior with JUnit 5, you should do the reverse what you do with JUni4 : remove @BeforeEach in the super class and add it only in the subclass.

public class BaseTestClass {

    public void setUp() {
        System.out.println("Base Test Class");
    }
}


public class InheritsFromBase extends BaseTestClass {

    @Override
    @BeforeEach
    public void setUp() {
        System.out.println("I inherit from base");
        super.setUp();
    }
}

As I execute the tests, it produces as output :

I inherit from base

Base Test Class

If you have somewhat of a legacy Java application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.

Internally we're using helpers to get/set private and private static variables as well as invoke private and private static methods. The following patterns will let you do pretty much anything related to the private methods and fields. Of course, you can't change private static final variables through reflection.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

And for fields:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

Notes:

1. TargetClass.getDeclaredMethod(methodName, argClasses) lets you look into private methods. The same thing applies for getDeclaredField.
2. The setAccessible(true) is required to play around with privates.

For some reason, your test suite, tries to load the MockitoJunitRunner from the org.mockito.junit contained in the Mockito versions >= 2. O. In that version, the line:

at org.mockito.junit.MockitoJUnitRunner.<init>(MockitoJUnitRunner.java:152)

is doing this:

public MockitoJUnitRunner(Class<?> klass) throws InvocationTargetException {
        //by default, StrictRunner is used. We can change that potentially based on feedback from users
        this(new StrictRunner(new RunnerFactory().createStrict(klass), klass));
    }

and the RunnerFactory that is loaded here is from version 1.x as createStrict has been introduced in Mockito 2.x.

So go through the pom dependency tree and to find what artifact implicitly add the Mockito 2.x dependency to your project and exclude it.

Alternatively.. as a workaround, instead of the @RunWith(MockitoJUnitRunner.class) you can use:

@Before
public void init() {
    MockitoAnnotations.initMocks(this);
}

You can also check out this Mockito cheat sheet to keep all the standards at hand.

You have two methods with the same name and return type, each with one parameter. So anyObject() matches both of them. That's why you get the batchWriteItem is ambiguous message.

You could use Mockito.any(Class<T> type) and Mockito.anyMapOf(Class<K> keyClazz, Class<V> valueClazz) to distinguish between them.

Docs for reference: any, anyMapOf

Try Cntrl + Shift + T on your eclipse screen. Check what are your results. Ideally eclipse should resolve this class only from one dependency. If you are getting multiple results, you may need to add exclusion on certain dependencies.

Also check if you are able to execute your test cases from command prompt. If you are able to do it, then it's not a maven problem. But if something is failing here, check your dependencies.

JUnit creates a new instance of test class each time it runs a new test method and runs @Before method each time it creates a new test class. You can easily test it:

@Before
public void setup() {
    System.out.println("setup");
    when(myMock.myMethod()).thenReturn("hello");
}

And MockitoJUnitRunner will create a new MyMock mock instance for every test method.

1. The test runner will effectively make a single Suite of all of your tests and run them - so that only one classloader is involved.
2. Yes that means that static data will be shared between tests, which can occasionally be handy, but will force you to cut down on the static coupling between clauses, which is a good thing.
3. There isn't generally any explicit GC, but you can do your own.

Generally running all your tests in one VM is a good thing. It forces you to look at static coupling and is a lot quicker. Crucially, it's also the way that your IDE will be running them, and that really is the way that tests should be run - as close as possible to as often as you compile.

For anyone still looking, blork had the right idea - you need to compile your native libraries for your 'native' platform (Windows, Linux, Mac). The Android NDK builds libraries for the Android platform (.so files - might also work on Linux), and this is why there are no issues running in Activity Test Cases (because it loads up an Android instance).

To get the low-level, hella fast JUnit tests running, you need to support your JVM. On Windows, this might be building DLLs, on Apple, it's building dylibs (assuming shared libraries).

I've just completed a sample in my android-ndk-swig-example repo (https://github.com/sureshjoshi/android-ndk-swig-example/issues/9).

Basically, in my CMakeLists, I added an Apple caveat:

# Need to create the .dylib and .jnilib files in order to run JUnit tests
if (APPLE)
    # Ensure jni.h is found
    find_package(JNI REQUIRED)
    include_directories(${JAVA_INCLUDE_PATH})

And then I make sure Gradle runs for unit tests, but using the Mac build system (not NDK).

def osxDir = projectDir.absolutePath + '/.externalNativeBuild/cmake/debug/osx/'

task createBuildDir() {
    def folder = new File(osxDir)
    if (!folder.exists()) {
        folder.mkdirs()
    }
}

task runCMake(type: Exec) {
    dependsOn createBuildDir
    workingDir osxDir // Jump to future build directory
    commandLine '/usr/local/bin/cmake' // Path from HomeBrew installation
    args '../../../../' // Relative path for out-of-source builds
}

task runMake(type: Exec) {
    dependsOn runCMake
    workingDir osxDir
    commandLine 'make'
}

 project.afterEvaluate {
    // Not sure how much of a hack this is - but it allows CMake/SWIG to run before Android Studio
    // complains about missing generated files
    // TODO: Probably need a release hook too?
    javaPreCompileDebug.dependsOn externalNativeBuildDebug
    if (org.gradle.internal.os.OperatingSystem.current().isMacOsX()) {
        javaPreCompileDebugAndroidTest.dependsOn runMake
    }
 }

CAVEAT TIME!!!

When you use this method, you're technically not testing the NDK-generated libs. You're testing the same code, but compiled using a different compiler (msvc, xcode, gcc, clang, whatever you use on the host).

What this means practically, is that most of the test results will be valid - except when you run into problems caused by each compiler's quirks, or STL implementations, etc... This isn't as bad as it was 10+ years ago, but you can't say with 100% certainty that the results of JUnit testing with host libs is identical to the Android libs. You can say that it's reasonably close, though.

Then again, unless you're running your native unit tests using the Android NDK for each supported architecture, you also can't say anything about certainty either... So take what you will from it.

An overkill approach (but really cool if automated) would be to write your native unit tests however you do them (Google Test, Catch, etc), then compile and run your native libs and unit tests with the Android NDK per each architecture. This provides your C/C++ coverage across your potential target architectures.

From here, you could use the aforementioned host libs with JUnit to rapidly unit test your JNI layer interacting with your native lib. In your CI system, you should still probably run these same unit tests - but as Android Instrumentation tests (or something else that runs an emulated Android environment).

As with everything, wherever you have an interface, you can create mocks - but at some point, you'll need system/functional/integration tests too.

Update:

More comprehensive explanation of above in a blog article (http://www.sureshjoshi.com/mobile/android-junit-native-libraries/)