How to use getFailures method of org.junit.runners.model.MultipleFailureException class

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

OK, I should have searched SO better.

Class teardown in junit 3?

public static Test suite() {
  return new TestSetup(new TestSuite(YourTestClass.class)) {

    protected void setUp() throws Exception {
        System.out.println(" Global setUp ");
    }
    protected void tearDown() throws Exception {
        System.out.println(" Global tearDown ");
    }
  };
}

Take a look at junit categories.

You'd tag your tests with specific category annotations

public interface FastTests { /* category marker */ }
public interface SlowTests { /* category marker */ }

@Category(SlowTests.class)
public class A {
    @Test public void a() {}
}

then form a suite like

@RunWith(Categories.class)
@IncludeCategory({FastTests.class})
@SuiteClasses({A.class, B.class})
public static class FastTestSuite {
     //
}

And then run it with

mvn -Dtest=FastTestSuite test

Note also that if you don't want to manually specify your unit test case classes in the suite class, you can also use the help of ClasspathSuite and then just limit based on categories.

While there is no only right way, the usual approach is to keep unit tests in the same project.

You can create a second source folder (like test), where you put your test classes into the same packages as the classes under test. This also allows you to test package-private classes while not flooding your main source packages with test classes.

Your source folder/package structure would then look like this:

-sources
   -main
       -my.package
             -MyClass.java
   -test
       -my.package
             -MyClassTest.java

You can then configure your build to not include the test source folder when packing the JAR.

Since Mockito 2.20 it is also possible, to add lenient() locally

@ExtendWith(MockitoExtension.class)
public class MockitoExample {

  static abstract class TestClass {
    public abstract int booleanMethod(boolean arg);
  }

  @Mock
  TestClass testClass;

  @BeforeEach
  public void beforeEach() {
    lenient().when(testClass.booleanMethod(eq(true))).thenReturn(1);
    lenient().when(testClass.booleanMethod(eq(false))).thenReturn(2);
  }

  @Test
  public void test() {
    assertEquals(1,testClass.booleanMethod(true));
    assertEquals(2,testClass.booleanMethod(false));
  }
}

It's deprecated because of the double's precision problems.

If you note, there's another method assertEquals(double expected, double actual, double delta) which allows a delta precision loss.

JavaDoc:

Asserts that two doubles are equal to within a positive delta. If they are not, an AssertionError is thrown. If the expected value is infinity then the delta value is ignored.NaNs are considered equal: assertEquals(Double.NaN, Double.NaN, *) passes

...

delta - the maximum delta between expected and actual for which both numbers are still considered equal.

There may be better approaches, but there are also some frameworks that help implement benchmarking with JUnit. Some useful practices are warmup runs, statistical evaluations. Take a look at JUnitBenchmarks and JUnitPerf

EDIT looks like JUnitBenchmarks has been deprecated since the question has been stated. The project's maintainers recommend moving on to JMH. Thank you, Barry NL for the heads-up.

@TestInstance(PER_CLASS)

You may select the "single test instance per class" mode annotating the nested class with @TestInstance(TestInstance.Lifecycle.PER_CLASS):

class ColorTest {

    @Nested
    @TestInstance(TestInstance.Lifecycle.PER_CLASS)
    class Inner {

        @ParameterizedTest
        @MethodSource("colors")
        void blue(Color color, int blue) {
            Assertions.assertEquals(color.getBlue(), blue);
        }

        Stream<Arguments> colors() {
            return Stream.of(
                    Arguments.of(Color.BLACK, 0),
                    Arguments.of(Color.GRAY, 128),
                    Arguments.of(Color.BLUE, 255)
            );
        }
    }

}

When using this mode, a new test instance will be created once per test class.

ArgumentsProvider

Or you may switch from a MethodSource to an ArgumentsProvider.

I modified your example to see if it compiles and runs locally:

class ColorTest {

    static class Blues implements ArgumentsProvider {

        @Override
        public Stream<Arguments> provideArguments(ExtensionContext context) {
            return Stream.of(
                    Arguments.of(Color.BLACK, 0),
                    Arguments.of(Color.GRAY, 128),
                    Arguments.of(Color.BLUE, 255)
            );
        }
    }

    @Nested
    class Inner {

        @ParameterizedTest
        @ArgumentsSource(Blues.class)
        void blue(Color color, int blue) {
            Assertions.assertEquals(color.getBlue(), blue);
        }
    }

}

More details at http://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests

The code in the class you named TestController isn't a controller, it's a test, but the convention says that it's a controller (perhaps used in testing). By default, Surefire will be looking for tests matching *Test; rename the class to ControllerTest.