Restructure testing

[jdpedrie]

This pull request updates the four test suites to be (i think -- see below for more) fully compatible with the restructure. It also improves the management of snippet tests especially.

Unit, snippet and conformance tests can be run as a whole or on a single repository. System tests can be run against the full project just as they are now.

Next up is the pre-release tests of each component as a separate unit, which will have the added benefit of proving that the unit, snippet and conformance tests work as expected as a discrete suite (as opposed to as part of the umbrella). That'll be done early next week.

I placed a couple of bootstrap files in the root of Core. I'm not especially happy with that, but they need to be available to every component, so the umbrella tests folder wasn't an option. They can be moved quite easily though.

sidenote: you don't need to include the composer autoloader. phpunit will find it on its own.

[michaelbausor]

This looks really good!

Re the bootstrap files in the root of core - is it sensible to put them somewhere in Core/src/Testing? I am not sure whether that is better though.

[jdpedrie]

@michaelbausor @dwsupplee Added the component integration.

A new CLI called dev/google-cloud integration handles it.

If a component is updated and about to be released, the test will use the local copy of that component. Otherwise it will allow composer to install at the requested version.

The process in detail:

1. Copy each component into a folder called .testing.
2. Check the local version of each component, then check the latest published version (API call to github). If the local version is higher than the published version (i.e. we're about to release that component), we'll add the component to a list.
3. Each component is iterated over again. If that component requires or require-dev's a component in the first list (i.e. one which is about to be released), it'll be added to the list as well.
4. Each component's composer.json file is modified. Any dependencies in the list have their version requirement set to @dev. All the components which are in the list are added as path repositories, so they are symlinked rather than installed from remote.
5. Each component is iterated one last time, running composer install, then running unit and snippet tests. Any test failures or errors will stop execution.
6. .testing is deleted.

If you run this locally, I suggest making sure you're authenticated with github by setting the $GH_OAUTH_TOKEN environment variable, otherwise you'll get rate limited soon enough.

The latest commit also includes some fixes to composer files to provide dependencies required by tests.

We'll need to figure out how to integrate this into our process. I'd like to setup some sort of a Travis trigger which will run against release pull requests. in the interim, it should be run locally before a release pull request is opened.

edit: it won't work out of the box until google/cloud-core is released with the new testing utilities. run dev/google-cloud release minor cloud-core locally first and it'll run.