Add an API transport for registration of URLs and payloads.

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

Information

RBTools
release-3.x

Reviewers

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.

Summary ID
Add an API transport for registration of URLs and payloads.
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.
1aa1b758a6c34d6b8a26c209dc89e79d43f5327e
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-3.x (084cd9a)
Loading...