Create a tests bundle for maven

[ajkannan]

Right now, test classes are not pushed to maven. However, some test classes are useful for users to test their own code locally, like LocalGcdHelper.

[aozarov]

It does look like we can push test artifacts and people can use them using a test-jar type.

I can see a potential value in having a test artifact (e.g. we could share base test classes,..) but
at the moment the only thing we care about is the test helper LocalGcdHelper and soon RemoteGcsHelper.

Another option we can take is to move these test-helpers which are not tests themselves to a "testing"
sub package in the main src directory (e.g. com.google.gcloud.datastore.testing.LocalGcdHelper in src/main).

The benefit of the latter is greater visibility for these helpers.
Also, another benefit is that they could have their own package-info.java with examples
of how to use them in tests (see issue #165).

Thoughts?

/cc @ajkannan @mziccard @jgeewax

[mziccard]

I see 3 options here:

1. Text artifact with test-jar type: people can re-use test classes (not only LocalGcdHelper and RemoteGcsHelper) and run the tests contained in the jar
2. Put helpers in a testing package inside each module's src
3. Create a gcloud-test module and put all helpers there

1. is the most flexible solution and also allows users to re-run tests from the jar (even though I struggle to find a reasonable use case for this for a user), 2) is also ok as I expect users to only reuse helpers, this also gives helpers more visibility and allows us to document their usage in package's javadoc 3) Has the same benefits of 2 (maybe less visibility?) and also puts all helpers in the same module.

I don't have a strong opinion. If we want users to reuse and rerun tests we must go with solution 1. Otherwise I think solutions 2 and 3 as equally good (I have a slight preference for 3).

[ajkannan]

I like the submodule option 2. I agree that it's hard to find a use case for option 1, and I have a slight preference for 2 over 3 since option 2 automatically gives users the relevant test classes without having to list another dependency.

[aozarov]

I have slight preference for option 2.

Mostly because I think it is simple and likely to have the best visibility (including a place to document it, per service, in their respective package-info).