This API allows to create and retrieve changes in a fluent manner with
minimal effort. Tests only need to specify the parameters which are
essential for them. They also don't need to care about permissions or
the current user context.
Examples:
- changeOperations.newChange().create()
- changeOperations.newChange().branch("test-branch").create()
- changeOperations.newChange().file("foo").content("bar").create()
- changeOperations.change(changeId).get()
Besides being much more convenient and readable than the existing
mechanisms to create test changes, this API tries to avoid
confusing/unintended behaviors. For instance, the traditional mechanism
for creating test changes involves the creation of a commit and its push
to the server. Subsequent change creations automatically create a chain
of changes if the repository is not explicitly reset. That behavior is
not obvious to callers in tests and can lead to frustrating/confusing
moments when writing tests. The new test API creates independent changes
on each call. Support for chains of changes is not implemented yet but
it would simply be a matter of passing the ID of a parent change/commit
along.
This API follows the same structure as the test APIs of groups and
accounts. The implementation is more complicated, though, as we
currently don't have clean internal APIs for change creation as we do
for groups and accounts. In addition, changes have some mandatory values
(project and change owner) which cannot be easily substituted with
arbitrary, hard-coded values. For those situations, we decided to look
for existing projects and users and to arbitrarily select one of them.
Of course, we could have created a new project/user instead but we
thought it's better not to introduce such a behavior as a side-effect to
a call for change creation. Overall, we tried to hide most of the
complexity behind the test API surface so that usages in tests can be as
simple as "changeOperations.newChange().create()".
Change retrieval currently supports only the barest of attributes.
Change creation is already more sophisticated and features quite some
input parameters including the handy "file("myFilePath").content
("myFileContent")" notation. Now that the base implementation is laid
out, it should be easy to add additional attributes when necessary.
Change-Id: I10b7455990a8439cf255853dae66b8f2da9085ab
3871ea3513