How to use MultipleFailureException class of org.junit.runners.model package

I had the same problem. Solved by adding url for missing repository in the build.gradle file:

android {
    [...]
    repositories {
        maven { url 'https://repo1.maven.org/maven2' }
    }
    [...]
}

That's it.

This is the site that help me solve the problem.

http://code.google.com/p/hamcrest/issues/detail?id=128

The hamcrest.jar needs to go before the Junit library in the build path.

You can use SpringClassRule and SpringMethodRule - supplied with Spring

import org.junit.ClassRule;
import org.junit.Rule;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.springframework.test.context.junit4.rules.SpringClassRule;
import org.springframework.test.context.junit4.rules.SpringMethodRule;

@RunWith(Parameterized.class)
@ContextConfiguration(...)
public class MyTest {

    @ClassRule
    public static final SpringClassRule SPRING_CLASS_RULE = new SpringClassRule();

    @Rule
    public final SpringMethodRule springMethodRule = new SpringMethodRule();

    ...

It might be a good idea if you want to programmatically decide which "profile" to run. Think of Spring Profiles for configuration. Inside an integration tests you might want to test against a different database.

Here is the tested code that works

public static boolean isJUnitTest() {  
  for (StackTraceElement element : Thread.currentThread().getStackTrace()) {
    if (element.getClassName().startsWith("org.junit.")) {
      return true;
    }           
  }
  return false;
}

An unexpected exception is a test failure, so you neither need nor want to catch one.

@Test
public void canConvertStringsToDecimals() {
    String str = "1.234";
    Assert.assertEquals(1.234, service.convert(str), 1.0e-4);
}

Until service does not throw an IllegalArgumentException because str has a decimal point in it, that will be a simple test failure.

An expected exception should be handled by the optional expected argument of @Test.

@Test(expected=NullPointerException.class)
public void cannotConvertNulls() {
    service.convert(null);
}

If the programmer was lazy and threw Exception, or if he had service return 0.0, the test will fail. Only an NPE will succeed. Note that subclasses of the expected exception also work. That's rare for NPEs, but common with IOExceptions and SQLExceptions.

In the rare case that you want to test for a specific exception message, you use the newish ExpectedException JUnit @Rule.

@Rule
public ExpectedException thrown= ExpectedException.none();
@Test
public void messageIncludesErrantTemperature() {
    thrown.expect(IllegalArgumentException.class);
    thrown.expectMessage("-400"); // Tests that the message contains -400.
    temperatureGauge.setTemperature(-400);
}

Now, unless the setTemperature throws an IAE and the message contains the temperature the user was trying to set, the test fails. This rule can be used in more sophisticated ways.

Your example can best be handled by:

private void testNumber(String word, int number)
        throws OutOfRangeNumberException {
    assertEquals(word,  service.convert(number));
}

@Test
public final void testZero()
        throws OutOfRangeNumberException {
    testNumber("zero", 0);
}

You can inline testNumber; now, it does not help much. You can turn this into a parametrized test class.

To provide the input from a file, make a FileInputStream and set that as the System.in stream. You'll probably want to set the original back after the main method has finished to make sure anything using it later still works (other tests, JUnit itself...)

Here's an example:

@Test
public void testMain() throws IOException {
    System.out.println("main");
    String[] args = null;
    final InputStream original = System.in;
    final FileInputStream fips = new FileInputStream(new File("[path_to_file]"));
    System.setIn(fips);
    Main.main(args);
    System.setIn(original);
}

In your actual code you'll want to handle any IOExceptions and use something better than a full path to the file (get it via the classloader), but this gives you the general idea.

EDIT:

A couple years and some more wisdom later, I'd have to agree with Michael Lloyd Lee mlk's answer as the better approach and what should be preferred if possible. In the class containing your main method (or even a separate class) there ought to be a method that accepts an arbitrary InputStream and the arguments array. It could be a static method. The main method then simply calls it with the System.in stream as argument.

public class Main {
    public static void main(String[] args) {
        start(System.in, args);
    }
    public static void start(InputStream input, String[] args) {
        // use input and args
    }
}

Or alternatively you could have a class with a constructor accepting the arguments array to create a properly configured instance and then call an instance method on it that accepts an InputStream, like so:

public class Main {
    public static void main(String[] args) {
        Bootstrapper bootstrapper = new Bootstrapper(args);
        bootstrapper.start(System.in);
    }
}

public class Bootstrapper { // just some name, could be anything else

    // could have some instance fields here...
    
    public Bootstrapper(String[] args) {
        // use the args to configure this instance, set fields, get resources...
    }
    
    public void start(InputStream input) {
        // use input
    }
}

Whatever fits the requirements and program design best. In both cases you end up with something that can be unit-tested with an InputStream obtained from a file. A test doing a simple static method call to Main.start, or a test creating a Bootstrapper instance and then calling its start method. Now your testing is no longer dependent on the System.in stream. The main method does minimal work and is simple enough for you to just trust its correctness without a separate test. At some point a piece of code becomes so trivial that testing it is equivalent to distrusting the compiler. And an issue in these main methods would become apparent very soon as it's the one method you know will always be called. A main method that does too much or is complex usually points to a lack of modularization in the code.

I leave the original answer in because it does offer a solution in case you really can't get past the use of System.in and testing the main method. That's why I wrote it in the first place, because I couldn't be certain about the asker's constraints. Sometimes someone just wants a straight answer to their exact question because the better approach is not available; you're not allowed to change the code, or refactoring it is too much effort and there's no budget, or some library is used that is hardcoded to use the system streams etc. Note that the original answer is less robust anyway. If the tests are run in parallel instead of sequentially, swapping out a system stream could cause unexpected and inconsistent failures.

Try this:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = TestApplication.class, 
    initializers = ConfigFileApplicationContextInitializer.class)
public class SomeTestClass {
    ...
}

EDIT:

For Spring Boot version 1.5+, SpringApplicationConfiguration was removed in favour of SpringBootTest or direct use of SpringBootContextLoader.

You can still use initializers parameter with ContextConfiguration annotation.

In a general way, what you did with @Rule and @ClassRule in JUnit 4 should be done with @ExtendWith and Extension that associated provide a very close feature in JUnit 5.
It works as standards JUnit lifecycle hooks but that it is extracted in a Extension class. And similarly to @Rule, as many Extensions as required may be added for a test class.

To handle the issue you have several possible approaches among :

• keep the JUnit 4 way (JUnit 5 owns the JUnit Vintage part that allows to execute JUnit 3 or 4 tests).
• rewrite the @Rule as an Extension.
• do the actual processing done by WireMockRule (start the server, execute your tests and stop the server) in each test of class with @BeforeEach and @AfterEach hook methods.
• use a third library that implements the equivalent of WireMockRule in the JUnit 5 Extension way such as https://github.com/lanwen/wiremock-junit5

Note that your issue already discussed in the JUnit 5 Issues.

At first you should check your test logic. Usually there are 3 cases. First, you are mocking the wrong method (you made a typo or someone changed tested code so that mocked method is no longer used). Second, your test is failing before this method is called. Third, your logic falls in wrong if/switch branch somewhere in the code so that mocked method is not called.

If this is the first case you always want to change the mocked method for the one used in the code. With the second and the third it depends. Usually you should just delete this mock if it has no use. But sometimes there are certain cases in parametrized tests, which should take this different path or fail earlier. Then you can split this test into two or more separate ones but that's not always good looking. 3 test methods with possibly 3 arguments providers can make your test look unreadable. In that case for JUnit 4 you silent this exception with either

@RunWith(MockitoJUnitRunner.Silent.class) 

annotation or if you are using rule approach

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.LENIENT);

or (the same behaviour)

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

For JUnit 5 tests you can silence this exception using this annotation provided in mockito-junit-jupiter package:

@ExtendWith(MockitoExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class JUnit5MockitoTest {
}