|
17 | 17 | Reference Docs in Tests |
18 | 18 | ======================= |
19 | 19 |
|
20 | | -In tests, you want to reference requirements (needs). |
21 | | -The docs-as-code tool will create backlinks in the documentation. |
| 20 | +This guide explains how to annotate test cases so that |
| 21 | +docs-as-code automatically creates traceability links between tests and requirements. |
22 | 22 |
|
23 | | -Docs-as-code parses `test.xml` files produced by Bazel under `bazel-testlogs/`. |
24 | | -To attach metadata to tests use the project tooling decorator (provided by the |
25 | | -attribute plugin). Example usage: |
| 23 | +The mechanism is language-agnostic: |
| 24 | +Bazel produces JUnit-style ``test.xml`` files under ``bazel-testlogs/``. |
| 25 | +The ``score_source_code_linker`` extension parses those files, extracts test metadata |
| 26 | +(name, file, line, result, and verification properties), |
| 27 | +and creates backlinks on the referenced requirements. |
26 | 28 |
|
27 | | -.. code-block:: python |
| 29 | +Required Properties |
| 30 | +------------------- |
28 | 31 |
|
29 | | - from attribute_plugin import add_test_properties |
| 32 | +Every linked test must declare the following properties |
| 33 | +(see :need:`gd_guidl__verification_specification`): |
30 | 34 |
|
31 | | - @add_test_properties( |
32 | | - partially_verifies=["tool_req__docs_common_attr_title", "tool_req__docs_common_attr_description"], |
33 | | - test_type="interface-test", |
34 | | - derivation_technique="boundary-values", |
35 | | - ) |
36 | | - def test_feature(): |
37 | | - """Short description of what the test does.""" |
38 | | - ... |
| 35 | +``PartiallyVerifies`` *and/or* ``FullyVerifies`` |
| 36 | + Comma-separated list of requirement IDs that the test covers. |
39 | 37 |
|
40 | | -TestLink will extract test name, file, line, result and verification lists |
41 | | -(`PartiallyVerifies`, `FullyVerifies`) and create external needs from tests |
42 | | -and `testlink` attributes on requirements that reference the test. |
| 38 | +``TestType`` |
| 39 | + For example ``requirements-based``, ``interface-test``, or ``fault-injection``. |
43 | 40 |
|
44 | | -.. hint:: |
45 | | - It is possible to have 'additional' properties on tests. They will not show up in the |
46 | | - TestLink but also won't break the parsing process. |
| 41 | +``DerivationTechnique`` |
| 42 | + For example ``boundary-values``, ``equivalence-classes``, or ``error-guessing``. |
47 | 43 |
|
| 44 | +``Description`` |
| 45 | + A human-readable explanation of the test objective and expected outcome. |
48 | 46 |
|
| 47 | +If any mandatory property is missing the test will be skipped during link creation. |
49 | 48 |
|
50 | | -Limitations |
51 | | ------------ |
| 49 | +Language-Specific Annotations |
| 50 | +----------------------------- |
| 51 | + |
| 52 | +Each language uses a different mechanism to attach properties to test cases, |
| 53 | +but all produce the same JUnit XML output that the linker consumes. |
| 54 | + |
| 55 | +C++ (gTest) |
| 56 | + Use ``RecordProperty`` — shared properties go in ``SetUp()``, per-test properties |
| 57 | + inside each ``TEST_F``. |
| 58 | + See :need:`gd_req__verification_link_tests_cpp`. |
| 59 | + |
| 60 | +Rust |
| 61 | + Use the ``#[record_property]`` attribute macro from the ``test_properties`` crate. |
| 62 | + See :need:`gd_req__verification_link_tests_rust`. |
| 63 | + |
| 64 | +Python (pytest) |
| 65 | + Use the ``@add_test_properties`` decorator; the docstring serves as ``Description``. |
| 66 | + See :need:`gd_req__verification_link_tests_python`. |
| 67 | + |
| 68 | +See :need:`gd_temp__verification_specification` for code templates. |
| 69 | + |
| 70 | +Running Tests and Building Docs |
| 71 | +------------------------------- |
52 | 72 |
|
53 | | -- Not compatible with Esbonio/Live_preview. |
54 | | -- To create a valid Testlink Tags and XML must match the expected format. |
55 | | -- Partial properties will lead to no Testlink creation. |
56 | | - If you want a test to be linked, please ensure all requirement properties are provided. |
57 | | -- Tests must be executed by Bazel first so `test.xml` files exist. |
| 73 | +1. Execute tests so that ``test.xml`` files are generated: |
58 | 74 |
|
59 | | -Related |
60 | | -------- |
| 75 | + .. code-block:: bash |
| 76 | +
|
| 77 | + bazel test //... |
| 78 | +
|
| 79 | +2. Build the documentation — the linker picks up ``bazel-testlogs/`` automatically: |
| 80 | + |
| 81 | + .. code-block:: bash |
| 82 | +
|
| 83 | + bazel run //:docs |
| 84 | +
|
| 85 | +The resulting documentation shows backlinks on each requirement that is referenced by at least one test. |
| 86 | + |
| 87 | +Limitations |
| 88 | +----------- |
61 | 89 |
|
62 | | -For end-to-end dashboard and CI threshold setup, see |
63 | | -:doc:`dashboards_and_quality_gates`. |
| 90 | +- Tests must be executed by Bazel before building docs so ``test.xml`` files exist. |
| 91 | +- Not compatible with Esbonio / live preview (no ``bazel-testlogs/`` available). |
| 92 | +- All mandatory properties must be present; partial metadata causes the test to be silently skipped. |
0 commit comments