The test infrastructure and a first batch of tests were introduced in alpha1.
We switched to JUnit in the meantime, the infrastructure provides JUnit rules.
The 4.x tests so far consist of only unit tests, which we define as tests that don't start an external process. Obviously, we'll want more coarse-grained tests, with real over-the-network interactions with either a mock server (Scassandra / Simulacron), or ultimately a real Cassandra instance.
Create a new module for the test infrastructure (contains the equivalent of 3.x's CcmBridge, CCMTestsSupport, etc.). Suggested artifact id: java-driver-test-infra. This is primarily for our internal use, but will be published to central as well for external users. For this reason I think we should commit to semver with an api/internal package scheme, like the rest of the project.
Create a new module for the integration tests. Suggested artifact id: java-driver-integration-tests. This one is not published in central, only run as part of the build. This structure avoids cyclic dependencies:
We also keep the two test suites cleanly separated, allowing distinct schedules (e.g. unit tests on each commit, integration tests nightly).
On a side note, I'd like to point out that 4.x is a blank slate that gives us the opportunity to aggressively get rid of complexity; frankly, I find the annotations in 3.x daunting. I wouldn't mind having a bit more code to write in each test in exchange for less "magic", and more understanding of what's going on (but that's up for debate).
In the same vein, I don't know how far we want to go with test framework integration. We need to find a good balance between supporting every test framework under the sun, or limiting our dependencies and API surface. Maybe external users can write their own Junit rule.