How to use InvalidOrderingException class of org.junit.runner.manipulation package

There's actually an alternative to the @Test(expected=Xyz.class) in JUnit 4.7 using Rule and ExpectedException

In your test case you declare an ExpectedException annotated with @Rule, and assign it a default value of ExpectedException.none(). Then in your test that expects an exception you replace the value with the actual expected value. The advantage of this is that without using the ugly try/catch method, you can further specify what the message within the exception was

@Rule public ExpectedException thrown= ExpectedException.none();

@Test
public void myTest() {
    thrown.expect( Exception.class );
    thrown.expectMessage("Init Gold must be >= 0");

    rodgers = new Pirate("Dread Pirate Rodgers" , -100);
}

Using this method, you might be able to test for the message in the generic exception to be something specific.

ADDITION Another advantage of using ExpectedException is that you can more precisely scope the exception within the context of the test case. If you are only using @Test(expected=Xyz.class) annotation on the test, then the Xyz exception can be thrown anywhere in the test code -- including any test setup or pre-asserts within the test method. This can lead to a false positive.

Using ExpectedException, you can defer specifying the thrown.expect(Xyz.class) until after any setup and pre-asserts, just prior to actually invoking the method under test. Thus, you more accurately scope the exception to be thrown by the actual method invocation rather than any of the test fixture itself.

JUnit 5 NOTE:

JUnit 5 JUnit Jupiter has removed @Test(expected=...), @Rule and ExpectedException altogether. They are replaced with the new assertThrows(), which requires the use of Java 8 and lambda syntax. ExpectedException is still available for use in JUnit 5 through JUnit Vintage. Also JUnit Jupiter will also continue to support JUnit 4 ExpectedException through use of the junit-jupiter-migrationsupport module, but only if you add an additional class-level annotation of @EnableRuleMigrationSupport.

You can add this task:

task copyLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

Dependencies will be downloaded from your Nexus, but when you need package the library, execute this task first and jar files will be copied and included inside final aar.

Declare the exception in the test method.

public void testAddUser() throws ServiceException {
...
}

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.

In the JUnit Run configuration set the Test kind to Pattern, specify the following regular expression as the pattern:

^(?!.*IT$).*$

It matches against the class name, so you don't need to match .java extension. Regular expression will not match if the class name ends with IT using the negative lookahead.

There are several ways you can do this.

• If you're only incrementing, you can use a counter element
• You can use any number of functions to calculate the value
• You can read from a CSV file, which is the same effect as "StringFromFile" but easier to customize and manipulate

Given you have an array of values you could:

• Try the pre-processor "User Parameters", creating one entry for each user/loop
• Use a Beanshell script to create the array, select one at random and populate your variable

You reference them exactly as you have listed: ${varName}

Maven has since been updated and can use categories.

An example from the Surefire documentation:

<plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.11</version>
      <configuration>
        <groups>com.mycompany.SlowTests</groups>
      </configuration>
</plugin>

This will run any class with the annotation @Category(com.mycompany.SlowTests.class)

I'm the creator of TestNG and author of the "Next Generation Testing" book, so here are a few (obviously biased) thoughts.

For functional (or end to end / integration / system, whatever term you prefer) testing, TestNG offers a few features that JUnit doesn't have and that users have found very useful:

• Groups. Once you have compiled your tests, you can just ask TestNG to run all the "front-end" tests, or "fast", "slow", "database", etc...

• Support for multithreaded testing. This has two different meanings:

1) You can tell TestNG to run all your tests concurrently in thread pools that you define (one line change in an XML file). This is very configurable so that tests that are not multithreaded can still be run in single threads.

2) You can tell TestNG to invoke your test methods n times from p threads. This gives you a good idea of how thread safe the code you are testing is.

• Test dependencies and deterministic ordering. This is very useful for integration testing where it's very common to see test methods that need prior test methods to succeed before they can even run. TestNG is very popular in the Selenium community for this specific reason ("don't bother testing this page of my web site if the login test failed").

Another immediate advantage of test dependencies is that TestNG can tell you "1 method failed, 99 methods skipped", which is a much more accurate result than "100 methods failed".

TestNG has many, many more features and I'm happy to answer questions here or on our mailing-list (http://groups.google.com/group/testng-users ).

The easiest (as in least amount of new code required) way to do this is to run the test as a parametrized test (annotate with an @RunWith(Parameterized.class) and add a method to provide 10 empty parameters). That way the framework will run the test 10 times.

This test would need to be the only test in the class, or better put all test methods should need to be run 10 times in the class.

Here is an example:

@RunWith(Parameterized.class)
public class RunTenTimes {

    @Parameterized.Parameters
    public static Object[][] data() {
        return new Object[10][0];
    }

    public RunTenTimes() {
    }

    @Test
    public void runsTenTimes() {
        System.out.println("run");
    }
}

With the above, it is possible to even do it with a parameter-less constructor, but I'm not sure if the framework authors intended that, or if that will break in the future.

If you are implementing your own runner, then you could have the runner run the test 10 times. If you are using a third party runner, then with 4.7, you can use the new @Rule annotation and implement the MethodRule interface so that it takes the statement and executes it 10 times in a for loop. The current disadvantage of this approach is that @Before and @After get run only once. This will likely change in the next version of JUnit (the @Before will run after the @Rule), but regardless you will be acting on the same instance of the object (something that isn't true of the Parameterized runner). This assumes that whatever runner you are running the class with correctly recognizes the @Rule annotations. That is only the case if it is delegating to the JUnit runners.

If you are running with a custom runner that does not recognize the @Rule annotation, then you are really stuck with having to write your own runner that delegates appropriately to that Runner and runs it 10 times.

Note that there are other ways to potentially solve this (such as the Theories runner) but they all require a runner. Unfortunately JUnit does not currently support layers of runners. That is a runner that chains other runners.