How to use BaseDescription class of org.hamcrest package

You will get this exception, if you use the JUnit 4.4 core runner to execute a class that has no "@Test" method. Kindly consult the link for more info.

courtesy vipin8169

Yes, it is possible. The easiest way for me at least is to add a test suite class. It can look like this:

package tests;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

import tests.message.ATest;
import tests.validator.BTest;
import tests.validator.CTest;
import tests.validator.DTest;

@RunWith(Suite.class)
@SuiteClasses({ ATest.class, 
        BTest.class, 
        CTest.class, 
        DTest.class })
public class AllTests {

}

This will allow you to test any class that you import no matter what package it is in. To run this in eclipse you just right click the AllTests class and run it as JUnit test. It will then run all the tests you define in @SuiteClasses.

This will work with linked sources as well, I use it all the time.

So two things

First, if you try to open Android Studio on Yosemite upgrade and it says "No JVM found" you need to install the java 6 for osx here as Android requires java 1.6 and not java 1.6+.

Second, The Exception I found was caused because it was trying to run JUnit as if I wanted to run through java standard console instead of with Android.

Do not use the Java test that contains a black with arrows, use the unit tests within a Android Tests and delete all uses of the JUnit configuration.

Your configuration should look like this, then you can right click on single tests and run them like normal.

You can add this task:

task copyLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

Dependencies will be downloaded from your Nexus, but when you need package the library, execute this task first and jar files will be copied and included inside final aar.

Ran into this as well. I'm using gradle to manage my tasks and I put this in at the end of by build.gradle file :

test {
  testLogging.showStandardStreams = true
}

Now I see System.out.println(whateves).

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.

You can make a custom, barebones JUnit runner fairly easily. Here's one that will run a single test method in the form com.package.TestClass#methodName:

import org.junit.runner.JUnitCore;
import org.junit.runner.Request;
import org.junit.runner.Result;

public class SingleJUnitTestRunner {
    public static void main(String... args) throws ClassNotFoundException {
        String[] classAndMethod = args[0].split("#");
        Request request = Request.method(Class.forName(classAndMethod[0]),
                classAndMethod[1]);

        Result result = new JUnitCore().run(request);
        System.exit(result.wasSuccessful() ? 0 : 1);
    }
}

You can invoke it like this:

> java -cp path/to/testclasses:path/to/junit-4.8.2.jar SingleJUnitTestRunner 
    com.mycompany.product.MyTest#testB

After a quick look in the JUnit source I came to the same conclusion as you that JUnit does not support this natively. This has never been a problem for me since IDEs all have custom JUnit integrations that allow you to run the test method under the cursor, among other actions. I have never run JUnit tests from the command line directly; I have always let either the IDE or build tool (Ant, Maven) take care of it. Especially since the default CLI entry point (JUnitCore) doesn't produce any result output other than a non-zero exit code on test failure(s).

NOTE: for JUnit version >= 4.9 you need hamcrest library in classpath

Take a look at the Hamcrest matchers, now included in JUnit. What you want is something like:

import static org.junit.Assert.assertThat;
import static org.hamcrest.CoreMatchers.instanceOf;

assertThat(receivedPacket, instanceOf(SomePacket.class));

That does everything you need, including a decent error message upon assertion failure.

[updated]

The Truth authors recommend using JUnit 4.13/5's assertThrows() mechanism, since this doesn't really need support in Truth. This would look more like:

SpecificException e = 
    assertThrows(SpecificException.class, () -> doSomethingThatThrows());
assertThat(e).hasMessageThat().contains("blah blah blah");
assertThat(e).hasCauseThat().isInstanceOf(IllegalStateException.class);
assertThat(e).hasCauseThat().hasMessageThat().contains("blah");

This is recommended over try/fail/catch as it is terser, avoids the "missing fail" problem, and returns an object that can be asserted-on using the ThrowableSubject in Truth.

If you do not have assertThrows(), then please use the try/fail/catch pattern, as this is clear and explicit.

try {
  doSomethingThatThrows(); 
  fail("method should throw");
} catch (SpecificException e) {
  // ensure that e was thrown from the right code-path
  // especially important if it's something as frequent
  // as an IllegalArgumentException, etc.
  assertThat(e).hasMessage("blah blah blah");
}

While @Rule ExpectedException and @Test(exception=...) exist in JUnit, these aren't recommended by the Truth team, insofar as they have some subtle (and less subtle) ways you can write tests that pass but which should fail.

While this is also true of try/fail/catch, internally Google mitigates this with the use of error-prone, which provides a static compile-time check to ensure that this pattern doesn't omit the fail(), etc. It is highly recommended that you use error-prone or another static analysis check to catch these. Sadly, the rule-based and annotation-based methods aren't as easily amenable to static analysis as this try/catch block.