How to use assertNotNull method of junit.framework.TestCase class

new File(path).toURI().toURL();

Even more meaningful :

import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;

// ...

verify(dependency, never()).someMethod();

The documentation of this feature is there §4 "Verifying exact number of invocations / at least x / never", and the never javadoc is here.

The 'Should' convention is aligned with the behaviour driven development style of testing.

I personally really prefer to write tests in this style, as it encourages you to write tests that read as specifications, and are more aligned with the behaviour of the class or system that you are testing.

Where possible, I sometimes go one step further and give the test class even more context using it's name:

class ANewlyCreatedAccount {
  shouldHaveAZeroBalance() {}
  shouldCalculateItsOwnInterest() {}
}

By naming your classes and thinking about them in this specification style, this can give you a lot of guidance on which tests to write, and in which order you should write the tests and make them green.

Yes, 'should' vs 'test' is just a prefix and it's important to be consistent, but this question is also about the style and mindset of how you test your code and choose which tests to write. BDD has a ton of value, so I suggest reading further and give this a try.

Try anyInt():

when(candidateService.findById(anyInt())).thenReturn(new Candidate());

For example I have anyLong() in my project:

when(dao.getAddress(anyLong())).thenReturn(Arrays.asList(dto));

EDIT: You must import:

import static org.mockito.Matchers.anyInt;

Just ran into this post trying to fix it for myself. Gave me just enough information to work it out.

You can give the compiler just enough to persuade it to compile by casting the return value from hasItems to a (raw) Matcher, eg:

ArrayList<Integer> actual = new ArrayList<Integer>();
ArrayList<Integer> expected = new ArrayList<Integer>();
actual.add(1);
expected.add(2);
assertThat(actual, (Matcher) hasItems(expected));

Just in case anybody else is still suffering ...

Edit to add: In spite of the up votes, this answer is wrong, as Arend points out below. The correct answer is to turn the expected into an array of Integers, as hamcrest is expecting:

    ArrayList<Integer> actual = new ArrayList<Integer>();
    ArrayList<Integer> expected = new ArrayList<Integer>();
    actual.add(1);
    expected.add(2);
    assertThat(actual, hasItems(expected.toArray(new Integer[expected.size()])));

And in classic fashion, I found what I was looking for moments after posting the question. Hopefully this will make it easier for the next person to find without first having to know what it's called. The magic method is the deceptively short-named as, which is part of another interface that AbstractAssert implements: Descriptable, not the base Assert interface.

public S as(String description, Object... args)

Sets the description of this object supporting String.format(String, Object...) syntax.
Example :

try {
  // set a bad age to Mr Frodo which is really 33 years old.
  frodo.setAge(50);
  // you can specify a test description with as() method or describedAs(), it supports String format args
  assertThat(frodo.getAge()).as("check %s's age", frodo.getName()).isEqualTo(33);
} catch (AssertionError e) {
  assertThat(e).hasMessage("[check Frodo's age] expected:<[33]> but was:<[50]>");
}

Where that quoted string in the catch block hasMessage is what appears in your unit test output log if the assertion fails.

I found this by noticing the failWithMessage helper in the custom assert page linked in the question. The JavaDoc for that method points out that it is protected, so it can't be used by callers to set a custom message. It does however mention the as helper:

Moreover, this method honors any description set with as(String, Object...) or overridden error message defined by the user with overridingErrorMessage(String, Object...).

... and the overridingErrorMessage helper, which completely replaces the standard AssertJ expected: ... but was:... message with the new string provided.

The AssertJ homepage doesn't mention either helper until the features highlights page, which shows examples of the as helper in the Soft Assertions section, but doesn't directly describe what it does.

Yes, you can. I was doing it couple of times to run diagnostic/smoke tests in production systems. This is a snippet of key part of the code invoking JUnit:

JUnitCore junit = new JUnitCore();
Result result = junit.run(testClasses);

DON'T use JUnit.main inside your application, it invokes System.exit after tests are finished and thus it may stop JVM process.

You may want to capture JUnit's "regular" console output (the dots and simple report). This can be easily done by registering TextListener (this class provides this simple report).

Please also be aware of several complications using this kind of method:

1. Testing of any "test framework", including so small one, although is quite simple may be confusing. For example if you want to test if your "test framework" return failure result when one of the tests fails you could (should?) create sample JUnit test that always fails and execute that test with the "test framework". In this case failing test case is actually test data and shouldn't be executed as "normal" JUnit. For an example of such tests you can refer to JUnit's internal test cases.

2. If you want to prepare / display your custom report you should rather register your own RunListener, because Result returned by JUnit doesn't contain (directly) information about passed tests and test method (it is only "hardcoded" as a part of test Description).

Try Cntrl + Shift + T on your eclipse screen. Check what are your results. Ideally eclipse should resolve this class only from one dependency. If you are getting multiple results, you may need to add exclusion on certain dependencies.

Also check if you are able to execute your test cases from command prompt. If you are able to do it, then it's not a maven problem. But if something is failing here, check your dependencies.

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.