@@ -49,6 +49,18 @@ divided into the NGSI-LD Test Suite Structure groups:
-[ContextSource](./files/ContextSource) contains the expected results of the Context Source files.
-[jsonldContext](./files/jsonldContext) contains the expected results of the Storing, Managing and Serving @contexts files.
## Rules for writing tests
When writing interoperability tests, store each payload as a valid UTF-8 JSON object with a unique, descriptive, hyphen-separated `.json` or `.jsonld` filename in either [`data/entities/interoperability`](../data/entities/interoperability) or [`data/csourceRegistrations/interoperability`](../data/csourceRegistrations/interoperability). Entity payloads must contain a `type` value of exactly `OffStreetParking` or `Vehicle`, while context source registration payloads must contain a `mode` value of exactly `inclusive`, `auxiliary`, `exclusive`, or `redirect`; these values determine the documentation clause, and the filename determines the generated figure label. When introducing another type, mode, or clause, update the mappings in [`statisticsDocumentationData.py`](./statisticsDocumentationData.py).
State the test objective with the suite-level `Documentation` setting in the `*** Settings ***` section. Use `...` continuation lines when the objective spans multiple lines. For interoperability tests, a test-level `[Documentation]` setting is not used to populate `test_objective`.
The documentation generator infers preconditions from the keyword selected by `Test Setup`. Place the relevant `Create Entity` and `Create List` calls directly in that setup keyword; calls made only in the test body or indirectly through another user keyword are not considered. A `Create Entity` call must provide the payload filename and a broker variable resolving to `${bN_url}` through the `broker_url` argument. It generates text stating that broker `bN` contains that payload. The presence of the optional `context` argument generates the user-context text; omit the argument when no user context is used. A registration is inferred only from a `Create List` call having exactly five arguments in the following order: entity information, registration payload, registration mode, target broker URL, and registering broker URL. Its mode must be one of `inclusive`, `auxiliary`, `exclusive`, or `redirect`, and its broker variables must use the `${bN_url}` form.
Add `[Tags]` to every test case. Use an `iop` tag for interoperability tests, one `cnf_NN` tag identifying the applicable configuration, numeric clause tags written with underscores such as `4_3_3`, and a `since_vX.Y.Z` tag identifying the first supported release. The numeric tags are converted to specification clause numbers, and all test cases in one file must use the same release tag. Add registration-behaviour tags such as `additive-inclusive`, `additive-auxiliary`, `proxy-exclusive`, or `proxy-redirect` when applicable. Tags may continue on lines beginning with `...`; the continuation marker is discarded.
Write every documentation step as a standalone line comment inside the test case, immediately before the Robot Framework statement it describes. A comment such as `# Client sends an HTTP GET request to b1` becomes one generated test step. To add details beneath a step, place consecutive comments beginning with `# -` after a normal parent comment. Do not use a `# -` item without a preceding parent comment, and do not rely on comments in setup keywords, keyword implementations, or trailing comments because only full-line comments from the test-case body populate `test_steps`.
