Skip to content

Latest commit

 

History

History
106 lines (81 loc) · 4.49 KB

README.md

File metadata and controls

106 lines (81 loc) · 4.49 KB
Raw

Remote ID automated testing interfaces

These interfaces define how the remote ID automated testing suite interacts with the systems under test.

Viewing locally

To view these YAML files locally:

docker run -it --rm -p 8080:8080 \
  -v $(pwd)/v1/observation.yaml:/usr/share/nginx/html/swagger.yaml \
  -e PORT=8080 -e SPEC_URL=swagger.yaml redocly/redoc

OR

docker run -it --rm -p 8080:8080 \
  -v $(pwd)/v1/injection.yaml:/usr/share/nginx/html/swagger.yaml \
  -e PORT=8080 -e SPEC_URL=swagger.yaml redocly/redoc

...then visit http://localhost:8080/ in a browser.

Architecture

The general architecture assumed by these interfaces looks like this:

Automated testing architecture

In this diagram, the Service Provider system under test is encompassed by the dotted red line. Each Service Provider USS wishing to use the automated testing system built with the interfaces in this folder would provide a test data injector tailored to their individual system. The automated test driver would create a test by providing a set of test data for each participating SP USS to inject into their system via the blue lines at the bottom of the diagram -- these blue lines are the injection interface defined in this folder. The SP USS's test data injector would receive the injected data via that interface, translate it into whatever form is necessary for their system, and cause it to be injected into their system in whichever manner was most appropriate (hopefully following as many of the same code paths true telemetry would follow as possible).

Meanwhile, the automated test driver would poll a display data test receiver provided by a Display Provider to observe the remote ID information currently available in the whole remote ID system under test. A Display Provider USS wishing to run the automated testing system built with the interfaces in this folder would provide a display data test receiver tailored to their individual system. This display data test receiver would collect all remote ID information available in a requested area, at the level of the Display Application, and provide that information to the automated test driver via the observation interface defined in this folder.

The automated test driver would perform a test by injecting test data into each participating Service Provider, polling the resulting information from the remote ID system via the display data test receiver, and checking that the observed data satisfied a set of success criteria (e.g., an injected flight was observed at the expected time, not observed at other times, had the right number of recent positions, etc).

Useful notes regarding implementation of the interfaces

Injection of test data

Two useful notes about the injection interface:

  • The implementing USS is allowed to modify most fields of the injected flights (notable exception: injection ID, see below), as long as they are returned to the test driver.
  • The implementing USS is allowed to 'cut' the injected flights into several logical flights, as long as they are returned to the test driver.

Identifiers

There are several identifiers defined and used by the automated test driver that are not to be confused.

Test ID

  • Injection interface: query parameter of the PUT /tests/{test_id} call.

This is an immutable ID generated by the automated test driver to identify a test run, which is composed of several injected test flights.

Injection ID

  • Injection interface: field requested_flights[].injection_id in the request body of the PUT /tests/{test_id} call.

This is an immutable ID generated by the automated test driver to identify an injected test flight. Note that this is distinct from the flight ID.

Flight (details) ID

  • Injection interface: field requested_flights[].details_responses[].details.id in the request body of the PUT /tests/{test_id} call;
  • Observation interface: field flights[].id in the 200 response body of the GET /display_data call;
  • Observation interface: query parameter of the GET /display_data/{id} call;
  • Observation interface: field id in the 200 response body of the GET /display_data/{id} call.

This is a mutable ID identifying a flight.

It is originally generated by the automated test driver but can, and probably would in most cases, be overridden by the USS implementing the injection interface.

It is used by the test driver to retrieve the injected flight through the observation interface.