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
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)
add_list_url()to add a list resource, or
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
They can also manipulate the
capabilitiesattribute to change API
capabilities as needed.
Handling is strict, so any malformed or missing URLs will trigger
To use the transport,
URLMapTransportcan be passed in as the
transport class to
Command. Upcoming changes will
make it easier to integrate this with
Commandfor unit testing.
Tested along with upcoming changes to
Commandunit testing, and
build a handful of unit tests for another upcoming change. All