TestNG

You can use the System.arraycopy method (yes, all lowercase). Javadoc. You can do more stuff with arrays using the java.util.Arrays class.

The assertEquals(Collection<?> actual, Collection<?> expected) documentation says:

Asserts that two collections contain the same elements in the same order. If they do not, an AssertionError is thrown.

Thus the content of the collections will be compared which, in case both the collections are empty, are equal.

Arquillian is NOT replacement for JUnit/TestNG, it is rather complementar - helps to manage lifecycle of the test and provides many useful extensions. In blackbox testing space, there are Graphene and Drone extensions.

I would encourage you to take a look at Graphene extension for Arquillian - these are focused on blackbox testing leveraging best practices such as Page Objects pattern:

https://github.com/arquillian/arquillian-graphene

Graphene also tightly connects to Drone extension for Arquillian that helps to configure WebDriver.

Both tools builds on top of WebDriver, they don't replace it.

I'm sure someone will consider my response "opinionated" and vote it down, but nevertheless I think that

Yes, if you have a test framework you are relying upon for your acceptance testing, the framework itself needs to be tested.

From my experience the value is in 2 areas:

1. Be able to change your framework with confidence. When you create some function, you know quite a lot about it, i.e. which use cases it supports, what it's designed to do, etc. But other people (or even you a year from now) may not have the same level of knowledge, even with documentation. So either new functions will pop up every time someone needs some slight modification in behavior (because they are not confident to change existing function), or someone may break whole bunch of acceptance tests.

   Best if those are true unit tests, able to run completely independently from anything (use mocks, predefined static test data, etc).

2. Protect yourself from unexpected changes / bugs in Selenium itself (or other important 3rd-party libraries). When you're updating Selenium to next version (and that usually needs to be done every 3-6 months), there's always a chance that they changed some default you were relying upon (and didn't even know), or broke something, or suddenly something returns a different exception, or does not throw exception where it previously did and so on. Of course no need to get carried away and duplicate Selenium own unit tests, but when it comes to non-trivial things, or relying on some features with poor documentation, those tests may help a lot.

   Those are integration tests. Ideally they should run against test-only webapp (not the real application) that replicate specifically tested behaviors in a way convenient for tests.

Of course some compromises possible as well. For example having a small subset of acceptance tests that are serving as unit / integration tests (they run first, and other tests only run if they are passing). Might be cheaper to begin with those and slowly migrate to proper unit/integration tests when you debug / fix issues in the test framework.

Another question is how do you separate tests testing your framework from actual acceptance tests for the product. What worked for me is keeping test framework and acceptance tests in 2 separate projects. That way I can change the framework, build it (which also includes running unit and integration tests) many times if needed. When all unit and integration tests are passing, then I can update the version used by actual acceptance tests.

I think what you want is parameterized tests. It's available if you're using JUnit4 (or TestNG). Since you mention JUnit, you'll want to look at the @RunWith(Parameterized.class) and @Parameters annotations' documentation.

With Java 8 streams (and using this question about converting a stream into array):

@DataProvider
public Object[][] studentProvider() {
    return studentList.stream()
        .map(student -> new Object[] { student })
        .toArray(Object[][]::new);
}

MethodSorters is a new class introduced after Junit 4.6 release. This class declared three types of execution order, which can be used in your test cases while executing them.

1. NAME_ASCENDING(MethodSorters.NAME_ASCENDING) - Sorts the test methods by the method name, in lexicographic order.

2. JVM(null) - Leaves the test methods in the order returned by the JVM. Note that the order from the JVM my vary from run to run.

3. DEFAULT(MethodSorter.DEFAULT) - Sorts the test methods in a deterministic, but not predictable, order.

.

import org.junit.FixMethodOrder;
import org.junit.Test;
import org.junit.runners.MethodSorters;

//Running test cases in order of method names in ascending order

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class OrderedTestCasesExecution {

    @Test
    public void secondTest() {
        System.out.println("Executing second test");
    }

    @Test
    public void firstTest() {
        System.out.println("Executing first test");
    }

    @Test
    public void thirdTest() {
        System.out.println("Executing third test");
    }
}

Output:

Executing first test
Executing second test
Executing third test

Reference: http://howtodoinjava.com/2012/11/24/ordered-testcases-execution-in-junit-4/

I had this exact same error. The problem for me was a mismatch in the version numbers for the Google App Engine SDK dependencies

I had:

• appengine-api-1.0-sdk: 1.8.1.1
• appengine-api-labs: 1.8.1.1
• appengine-api-stubs: 1.8.1.1
• appengine-testing: 1.8.1.1
• appengine-tools-sdk: 1.7.2

Once I updated appengine-tools-sdk to be the same version as the rest of the dependencies, my tests started passing again.

Thanks to M. Deinum. To solve my problem, I just replace the class AbstractTestNGSpringContextTests with AbstractTransactionalTestNGSpringContextTests.

package com.noahwm.hkapp.api;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.testng.AbstractTransactionalTestNGSpringContextTests;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
import org.testng.Assert;
import org.testng.annotations.Test;

import com.noahwm.hkapp.api.db.dao.AppUserDao;
import com.noahwm.hkapp.api.db.model.AppUser;
import com.noahwm.hkapp.api.service.AppUserService;

@ContextConfiguration(locations = { "classpath:applicationContext-test.xml" })
public class AppUserServiceTestNGTest extends AbstractTransactionalTestNGSpringContextTests {

  @Autowired
  private AppUserService appUserService;

  @Test
  @Rollback
  @Transactional
  public void testApp() {
    AppUser appUser = new AppUser();
    appUser.setAge(10);
    appUser.setGender("F");
    appUser.setMobilePhone("13219201034");
    appUser.setName("HKAPP Test");
    appUserService.createUser(appUser);
    String appUserId = appUser.getId();
    Assert.assertNotNull(appUserId);
  }
}