You can use Hamcrest matchers to get a clearer error message here:

int i = 2;
assertThat(i, Matchers.either(Matchers.is(3)).or(Matchers.is(5))

or

int i = 2;
assertThat(i, Matchers.anyOf(Matchers.is(3),Matchers.is(5)));

This will more clearly explain:

Expected: (is <3> or is <5>)
     but: was <2>

showing exactly the expectation and the incorrect value that was provided.

You project class-path has to include a version of junit-jupiter-params-xxx.jar, like junit-jupiter-params-5.0.0.jar from http://central.maven.org/maven2/org/junit/jupiter/junit-jupiter-params/5.0.0/

The blog post from codefx.org you link to says (edited to the current 5.0.0 release):

Getting started with parameterized tests is pretty easy but before the fun can begin you have to add the following dependency to your project:

Group ID: org.junit.jupiter
Artifact ID: junit-jupiter-params
Version: 5.0.0

Either download and add it manually, or if you're using a build tool with dependency management (Gradle, Maven, ...) configure the build script (build.gradle, pom.xml, ...) accordingly.

Find some generic samples here: https://github.com/junit-team/junit5-samples

Starting with version 5.4.0-M1 JUnit Jupiter provides an aggregator artifact that bundles all available Jupiter-defining artifacts for easy consumption. See https://sormuras.github.io/blog/2018-12-26-junit-jupiter-aggregator.html for details.

You're approaching this the wrong way. Just test your functionality: if an exception is thrown the test will automatically fail. If no exception is thrown, your tests will all turn up green.

I have noticed this question garners interest from time to time so I'll expand a little.

Background to unit testing

When you're unit testing it's important to define to yourself what you consider a unit of work. Basically: an extraction of your codebase that may or may not include multiple methods or classes that represents a single piece of functionality.

Or, as defined in The art of Unit Testing, 2nd Edition by Roy Osherove, page 11:

A unit test is an automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It's trustworthy, readable, and maintainable. It's consistent in its results as long as production code hasn't changed.

What is important to realize is that one unit of work usually isn't just one method but at the very basic level it is one method and after that it is encapsulated by other unit of works.

Ideally you should have a test method for each separate unit of work so you can always immediately view where things are going wrong. In this example there is a basic method called getUserById() which will return a user and there is a total of 3 unit of works.

The first unit of work should test whether or not a valid user is being returned in the case of valid and invalid input.
Any exceptions that are being thrown by the datasource have to be handled here: if no user is present there should be a test that demonstrates that an exception is thrown when the user can't be found. A sample of this could be the IllegalArgumentException which is caught with the @Test(expected = IllegalArgumentException.class) annotation.

Once you have handled all your usecases for this basic unit of work, you move up a level. Here you do exactly the same, but you only handle the exceptions that come from the level right below the current one. This keeps your testing code well structured and allows you to quickly run through the architecture to find where things go wrong, instead of having to hop all over the place.

Handling a tests' valid and faulty input

At this point it should be clear how we're going to handle these exceptions. There are 2 types of input: valid input and faulty input (the input is valid in the strict sense, but it's not correct).

When you work with valid input you're setting the implicit expectancy that whatever test you write, will work.

Such a method call can look like this: existingUserById_ShouldReturn_UserObject. If this method fails (e.g.: an exception is thrown) then you know something went wrong and you can start digging.

By adding another test (nonExistingUserById_ShouldThrow_IllegalArgumentException) that uses the faulty input and expects an exception you can see whether your method does what it is supposed to do with wrong input.

TL;DR

You were trying to do two things in your test: check for valid and faulty input. By splitting this into two method that each do one thing, you will have much clearer tests and a much better overview of where things go wrong.

By keeping the layered unit of works in mind you can also reduce the amount of tests you need for a layer that is higher in the hierarchy because you don't have to account for every thing that might have gone wrong in the lower layers: the layers below the current one are a virtual guarantee that your dependencies work and if something goes wrong, it's in your current layer (assuming the lower layers don't throw any errors themselves).

Use AllOf

 Assert.assertThat(test, CoreMatchers.allOf(
      containsString("foo"),
      containsString("bar"),
      containsString("bar2"),
      containsString("ba3")));

Here's one simple approach for checking if the files are exactly the same:

assertEquals("The files differ!", 
    FileUtils.readFileToString(file1, "utf-8"), 
    FileUtils.readFileToString(file2, "utf-8"));

Where file1 and file2 are File instances, and FileUtils is from Apache Commons IO.

Not much own code for you to maintain, which is always a plus. :) And very easy if you already happen to use Apache Commons in your project. But no nice, detailed error messages like in mark's solution.

Edit:
Heh, looking closer at the FileUtils API, there's an even simpler way:

assertTrue("The files differ!", FileUtils.contentEquals(file1, file2));

As a bonus, this version works for all files, not just text.

There are several solutions:

1. You can add a public constructor and call it from a test. While it doesn't make sense, it also doesn't hurt (much).

2. Create a dummy static instance (you can call the private constructor here). Ugly but you can give the field a name to communicate your intent (JUST_TO_SILENCE_COBERTURA is a good name).

3. You can let your test extend the helper class. That will intrinsically call the default constructor but your helper class can't be final anymore.

I suggest the last approach especially because the class can't be final anymore. If a consumer of your code wants to add another helper method, they can now extend the existing class and receive one handle to get to all helper methods. This creates a coupling of the helper methods which communicates the intent (these belong together) - which is impossible if the helper class is final

If you want to prevent users to accidentally instantiate the helper class, make it abstract instead of using a hidden constructor.

In case anyone comes here based on the Could not find method testCompile() error, by now the more probable cause is that you need to replace the deprecated testCompile by testImplementation. See What's the difference between implementation and compile in Gradle?

There is no reason to use a hack as suggested by StefanE.

At this point I'm pretty sure Junit5 Test Parameters does not support anything else than primitive types and CsvSource only one allowing mixing of the types.

Actually, JUnit Jupiter supports parameters of any type. It's just that the @CsvSource is limited to a few primitive types and String.

Thus instead of using a @CsvSource, you should use a @MethodSource as follows.

@ParameterizedTest
@MethodSource("generateData")
void shouldGetDataBit(int first, String second, List<String> third) {
    System.out.println(first);
    System.out.println(second);
    System.out.println(third);
}

static Stream<Arguments> generateData() {
    return Stream.of(
        Arguments.of(1, "foo", Arrays.asList("a", "b", "c")),
        Arguments.of(2, "bar", Arrays.asList("x", "y", "z"))
    );
}

You are confusing a Mock with a Spy.

In a mock all methods are stubbed and return "smart return types". This means that calling any method on a mocked class will do nothing unless you specify behaviour.

In a spy the original functionality of the class is still there but you can validate method invocations in a spy and also override method behaviour.

What you want is

MyProcessingAgent mockMyAgent = Mockito.spy(MyProcessingAgent.class);

A quick example:

static class TestClass {

    public String getThing() {
        return "Thing";
    }

    public String getOtherThing() {
        return getThing();
    }
}

public static void main(String[] args) {
    final TestClass testClass = Mockito.spy(new TestClass());
    Mockito.when(testClass.getThing()).thenReturn("Some Other thing");
    System.out.println(testClass.getOtherThing());
}

Output is:

Some Other thing

NB: You should really try to mock the dependencies for the class being tested not the class itself.