commit b39b794a3948878f8109288545b7e16831cdab53
author Marco Miller <marco.miller@ericsson.com> Fri Apr 03 15:21:22 2020 -0400
committer Marco Miller <marco.miller@ericsson.com> Fri Apr 03 16:40:52 2020 -0400
tree 3df0e9d059c41aa7f067e0d7c1410f75de0a83a0
parent 16406aa35e4331818d13460076e3c5620c8330f1

e2e-tests: Add support for automated project names

Introduce underscore-prefixed keywords for the scenario json data files.
Use such keywords for test project naming first, but pave the way for
other potential use cases. Ways of automatically generating test data
may emerge, beside setting environment data with framework's JAVA_OPTS.

Have the CloneUsingBothProtocols showcase scenario use _PROJECT like so.
Make that scenario enforce its class name as the test project name,
based on that specific underscore-prefixed keyword. The scenario then
automatically names the project it creates, clones and deletes. Make the
project used, named after its originating class, more explicit that way.

Make the CreateProject and DeleteProject scenarios support the PROJECT
name property. That property can optionnally be set through framework's
recent JAVA_OPTS support. However, enforce the aforementioned _PROJECT
automation for CloneUsingBothProtocols's aggregation of these two project
scenarios. To make the whole of that behaviour consistent, introduce the
ProjectSimulation class.

It is still possible for a misconfigured test environment to execute the
CloneUsingBothProtocols scenario with PROJECT name set, say, as in [1].
This leads to CreateProject and DeleteProject using 'project' as the
name of the project they create/delete. CloneUsingBothProtocols, which
aggregates them both as delegate scenarios, then fails to clone its
project automatically named 'CloneUsingBothProtocols'. It is then
necessary to unset [1], or use another aggregate scenario composition.

[1] JAVA_OPTS="-Dcom.google.gerrit.scenarios.project=project"

Change-Id: Ib060ed35c5c19a7f8aff05e8d0b856abde70be2e