Screaming Penguin

JUnit 4 stuff, may be old to many, but I have to refer back to my own list once in a while, so here goes:

@Test
public void testIndexOutOfBoundsExceptionNotRaised()
         throws IndexOutOfBoundsException
         ArrayList emptyList = new ArrayList();
         Object o = emptyList.get(0);
     }

@Test(expected=IndexOutOfBoundsException.class)
     public void testIndexOutOfBoundsException() {
         ArrayList emptyList = new ArrayList();
        Object o = emptyList.get(0);
     }

@Ignore

@Test(timeout=500)

Make your own runner, and use it to run:

public static class MultiRunner extends JUnit4ClassRunner {
   public MultiRunner(Class clazz) throws InitializationError {
     super(clazz);
   }
   @Override
   public void run(final RunNotifier notifier) {
     for(int i=0; i<1000; i++) {
       super.run(notifier);
     }
   }
}

@RunWith(MultiRunner.class)
public class MultiRunTest {

}

JUnit 4.4 and up has "assertThat" for use with the Hamcrest matchers. This
makes for easier/shorter assertions, and they read more like sentences.

http://junit.sourceforge.net/javadoc_40/org/junit/Assert.html#assertThat(T,%20org.hamcrest.Matcher)

You can use these "matchers" with assertThat:
http://code.google.com/p/hamcrest/wiki/Tutorial

http://junit.sourceforge.net/javadoc_40/org/junit/matchers/JUnitMatchers.html

Have to include Hamcrest as a "test" scope dep for this.

Many opinions on this, the basic answer though is test what you think
needs testing - http://junit.sourceforge.net/doc/faq/faq.htm#tests_5.

"Test until fear becomes boredom."

In general, getters and setters can be an anti-pattern unless you really
are using property style handling with JavaBeans (rather than just
saying "create getters and setters" in your IDE). So the first rule is
DON'T HAVE GETTERS AND SETTERS unless absolutely needed. Then the second
rule is that some other code should exercise those in general, so the
probably don't need explicit tests - UNLESS they do some weird state
changing stuff and aren't vanilla getters/setters (but that's also usually a bad idea).

Using those two rules, if you run coverage and you see getters and setters that aren't
covered, 98% of the time it's because you don't need them at all, not
because you forgot to test them. (Though the exception here is test
first development, then you have to consider them a bit more.)

Same deal, if you are more comfortable when they are tested, then yes.
Also, if you really do test FIRST development, which has advantages (but
not everyone likes it), that is when this really comes up. You can use
reflection or groovy to test these. If you don't do test first then
usually your other code should indeed exercise the private methods.

http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html