Add an API transport for registration of URLs and payloads.

Review Request #12241 — Created April 20, 2022 and submitted — Latest diff uploaded




We've had two prior attempts at creating a usable API transport for unit
tests. The first, MockTransport, simply does nothing. It's an empty
stub of a transport that could be subclassed. The second,
TestTransport, could hardcode one list and one root payload, but was
limited to that.

This implements a new transport that replaces these two. This one
provides a formal way of constructing as much or as little of an API
tree as needed for tests. It supports registering combinations of URLs
and HTTP methods to response information (payloads, headers, and HTTP
status codes).

By default, a standard root resource, API info resource, and repository
list resource is registered. We may want to add other defaults in the
future, but these are required for most API client usage.

Unit tests can call add_item_url() to add an item (or singleton)
resource, add_list_url() to add a list resource, or add_url() to add
a more generic response payload.

URLs can be modified after registration, allowing a unit test to change
aspects of the root resource or any other registered resource based on
their needs.

They can also manipulate the capabilities attribute to change API
capabilities as needed.

Handling is strict, so any malformed or missing URLs will trigger
assertion errors.

To use the transport, URLMapTransport can be passed in as the
transport class to RBClient or to Command. Upcoming changes will
make it easier to integrate this with Command for unit testing.

Tested along with upcoming changes to Command unit testing, and
build a handful of unit tests for another upcoming change. All
tests pass.