We all agree that JUnit should never be set to another scope than test. Generally speaking I don't think either that there is another solution than excluding the unwanted dependency, so we all agree that your are right to do it.

A SIMPLE CASE :

As Andreas Krueger says, there may be a risk with versions (I actually encountered it). Let say that the project's dependencies are the following:

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:2.0
     +-group2:projectB:3.8.1
  +-group2:projectB:4.11

Note that it is only a mere simplification of your case. Seeing this dependency tree, you would exclude the dependency projectB given by projectA :

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>2.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

After packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 3.8.1. Everything would be fine and the project would run without encountering any problem at all.

Then, a while after, let say that you decide to upgrade to the next version of project A, version 3.0 which adds new great features :

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>3.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

The problem is that you are not aware yet that projectA version 3.0 also have upgraded its dependency projectB to version 5.0 :

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:3.0
     +-group2:projectB:5.0
  +-group2:projectB:4.11

In that case, the exclusion you would have made a while ago excludes projectB version 5.0.

However, projectA version 3.0 needs the improvements from project B version 5.0. Because of the exclusion, after packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 5.0. At the moment you use any of projectA's new features, the program wouldn't run correctly.

WHAT WAS THE SOLUTION ?

I encountered this problem in a Java-EE project.

A team developped database services. They packaged it as projectA. Each time they updated the services, they also updated a file listing all their current dependencies and the current versions.

ProjectA was a dependency for the Java-EE project I was working on. Each time the service-team updated ProjectA, I also checked the versions' updates.

In fact, there is no harm in excluding a dependency. But each time you update a dependency where an exclusion has been set, You have to check :

• if this exclusion still makes sense.
• if you need to upgrade the version of the excluded dependency in your own project.

I guess maven exclusions are like kitchen knifes. It's sharp, cuts vegetables with no effort, but requires care when handling it...

I want to use the assertArrayEquals(ArrayList<Token>, ArrayList<Token>) with these arguments (i.e. arrayList of tokens). But Java tells me I need to create such a method.

It's telling you that you need to create the method because there is no such method in the JUnit library. There isn't such a method in the JUnit library because assertArrayEquals is for comparing arrays, and and ArrayList is not an array—it's a List.

Is there a way to test for the equality of two arrayLists of whatever type in Junit?

You can check the equality of two ArrayLists (really, any two List objects) using equals, so you should be able to use JUnit's assertEquals method and it will work just fine.

Your methods seem to override some important initialization made in parent JerseyTest. Try to name them differently. E.g.:

@Before
public void setUpChild() { }

@After
public void tearDownChild() { }

I think you're looking for Matchers.hasItem(..)

Assert.assertThat(items, Matchers.hasItem(Matchers.hasToString("c")));

which states

Creates a matcher for Iterables that only matches when a single pass over the examined Iterable yields at least one item that is matched by the specified itemMatcher. Whilst matching, the traversal of the examined Iterable will stop as soon as a matching item is found.

Matchers.contains, as you stated,

Creates a matcher for Iterables that matches when a single pass over the examined Iterable yields a single item that satisfies the specified matcher. For a positive match, the examined iterable must only yield one item.

It seems to me like that's saying there should only be one element in the Iterable.

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.

Yes, all three methods will run within the same transaction. See section TestContext Framework/Transaction management in the reference docs:

Any before methods (such as methods annotated with JUnit's @Before) and any after methods (such as methods annotated with JUnit's @After) are executed within a transaction

Thus the @Transactional annotation on mySetup() and myTeardown() is kind of redundant, or might be even considered misleading, as their transactionality is determined by the individual test method being currently executed.

This is because the beforeTestMethod() and afterTestMethod() callbacks of TransactionalTestExecutionListener (responsible for starting/completing the transaction) are executed before JUnit's @Before and after JUnit's @After methods, respectively.

By default Maven uses the following naming conventions when looking for tests to run:

• Test*
• *Test
• *Tests (has been added in Maven Surefire Plugin 2.20)
• *TestCase

If your test class doesn't follow these conventions you should rename it or configure Maven Surefire Plugin to use another pattern for test classes.

In case anyone stumbles upon this question and wants to see how to get Guice annotations working from unit tests, extend your tests from a base class like the one below and call injector.injectMembers(this);

public class TestBase {
    protected Injector injector = Guice.createInjector(new AbstractModule() {
        @Override
        protected void configure() {
            bind(HelloService.class);
        }
    });

    @Before
    public void setup () {
        injector.injectMembers(this);
    }
}

Then your test can get an injected HelloService like this

public class HelloServiceTest extends TestBase {
    @Inject
    HelloService service;

    @Test
    public void testService() throws Exception {
       //Do testing here
    }
}

Refer to this issue and this issue regarding JUnit 5 support on Android.

Add this build script dependency in your top-level build.gradle[.kts] file:

buildscript {
  dependencies {
    classpath("de.mannodermaus.gradle.plugins:android-junit5:1.8.2.1")
  }
}

And add these lines in your app or library build.gradle[.kts] file:

plugins {
  // ...
  id("de.mannodermaus.android-junit5")
}

dependencies {
  // Aggregator dependency on JUnit api, engine, and params
  testImplementation("org.junit.jupiter:junit-jupiter:5.9.1")
  // (Optional) If you also have JUnit 4-based tests
  testImplementation("junit:junit:4.13.2")
  testRuntimeOnly("org.junit.vintage:junit-vintage-engine:5.9.1")
}

You can use the above solution if you are using Android Gradle plugin 3.2.0 or higher and Gradle 4.7 or higher. For more information refer to the plugin GitHub page.

Extended answer

If you want to use JUnit 5 in your instrumented tests (androidTest source set) do the following:

1. Add these dependencies to your app or libray build script:

androidTestImplementation("de.mannodermaus.junit5:android-test-core:1.3.0")
androidTestRuntimeOnly("de.mannodermaus.junit5:android-test-runner:1.3.0")

2. Use ActivityScenarioExtension instead of ActivityScenarioRule in your test classes:

import de.mannodermaus.junit5.ActivityScenarioExtension

class MyActivityTest {

  @JvmField
  @RegisterExtension
  val scenarioExtension = ActivityScenarioExtension.launch<MyActivity>()

  @Test
  fun test1() {
    val scenario = scenarioExtension.scenario
    scenario.moveToState(Lifecycle.State.RESUMED)
    assertThat(scenario.state).isEqualTo(Lifecycle.State.RESUMED)
  }

  @Test
  fun test2(scenario: ActivityScenario<MyActivity>) {
    scenario.moveToState(Lifecycle.State.RESUMED)
    assertThat(scenario.state).isEqualTo(Lifecycle.State.RESUMED)
  }
}