Skip to main content

kms-test-vector

Walk through the full KMS test vector creation workflow: directory, manifest.toml, TTLV steps, vector_runner.rs registration, README count. Use when creating test vectors.

Source facts

Repository
cosmian/kms
Last source activity
August 7, 2026 at 21:50
Detected SKILL.md language
English
Stars
362
Forks
41

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
kms-test-vector
description
Walk through the full KMS test vector creation workflow: directory, manifest.toml, TTLV steps, vector_runner.rs registration, README count. Use when creating test vectors.
# KMS Test Vector Creator Walk through the complete test vector creation workflow for the Eviden KMS. ## When to Use - After implementing a new feature or bug fix with behavioral change - When adding a new KMIP operation - When adding a negative/error-path test case - After any change that produces new observable output **Skip only if** the change is purely refactoring with no behavioral difference and all existing test vectors pass unchanged. ## Step 1 — Determine Vector Category Ask the user (or infer from context): | Change type | Directory | |-------------|-----------| | Standard feature / bug fix | `test_data/vectors/<feature-name>/` | | Negative / error path test | `test_data/vectors/negative/<feature-name>/` | | HSM-specific behavior | `test_data/vectors/hsm/<hsm-model>/` | | Non-FIPS-only feature | `test_data/vectors/non-fips/<feature-name>/` | | Cloud provider integration | `test_data/vectors/<provider>/` | Check existing vectors to avoid duplication: ```bash ls test_data/vectors/ ``` ## Step 2 — Create the Vector Directory ```bash mkdir -p test_data/vectors/<category>/<vector-name> ``` ## Step 3 — Write manifest.toml Create `test_data/vectors/<category>/<vector-name>/manifest.toml`: ```toml # Vector manifest for <vector-name> description = "<What this vector tests — one sentence>" feature = "fips" # or "non-fips", "hsm", "interop" version = "2.1" # KMIP version: "2.1" or "1.4" # Steps are executed in order. Each step is a file in this directory. [[steps]] name = "01_create_key" request = "01_create_key_request.json" response = "01_create_key_response.json" expected_status = "Success" [[steps]] name = "02_get_key" request = "02_get_key_request.json" response = "02_get_key_response.json" expected_status = "Success" # For negative tests, set expected_status to the expected error: # expected_status = "InvalidMessage" # expected_status = "PermissionDenied" ``` ## Step 4 — Write TTLV Step Files Each step needs a request JSON and (optionally) response JSON. Request files follow the TTLV-over-JSON format used by `crate/kmip/src/`: ```json { "tag": "RequestMessage", "value": [ { "tag": "RequestHeader", "value": [ {"tag": "ProtocolVersion", "value": [ {"tag": "ProtocolVersionMajor", "type": "Integer", "value": 2}, {"tag": "ProtocolVersionMinor", "type": "Integer", "value": 1} ]}, {"tag": "BatchCount", "type": "Integer", "value": 1} ] }, { "tag": "BatchItem", "value": [ {"tag": "Operation", "type": "Enumeration", "value": "Create"}, {"tag": "RequestPayload", "value": [ // ... operation-specific fields ]} ] } ] } ``` **Source example values from existing test vectors** — never invent key material or algorithm parameters: ```bash ls test_data/vectors/ cat test_data/vectors/<similar-vector>/<step>.json ``` ## Step 5 — Register in vector_runner.rs Open `crate/test_kms_server/src/vector_runner.rs` and add a new test function: ```rust #[tokio::test] async fn test_<vector_name>() { run_vector("test_data/vectors/<category>/<vector-name>").await; } ``` Follow the naming convention of existing tests in that file. ## Step 6 — Run and Verify ```bash # Run only the new vector cargo test -p test_kms_server test_<vector_name> ``` If the test fails: 1. Check the error message — does the request JSON have the correct TTLV structure? 2. Compare with a passing similar vector 3. Check `crate/test_kms_server/src/vector_runner.rs` for how vectors are loaded Fix any failure before proceeding. ## Step 7 — Update README Open `crate/test_kms_server/README.md`: 1. Add a row to the vector table: ```markdown | `<category>/<vector-name>` | <KMIP version> | <feature> | <Description> | ``` 2. Increment the total vector count at the top of the table. ```bash # Verify the count is accurate find test_data/vectors -name "manifest.toml" | wc -l ``` ## Summary Checklist - [ ] Directory created: `test_data/vectors/<category>/<name>/` - [ ] `manifest.toml` written with correct steps and `expected_status` - [ ] Request JSON files written (sourced from real data, not invented) - [ ] Response JSON files written (or omitted for negative tests) - [ ] Test function added to `crate/test_kms_server/src/vector_runner.rs` - [ ] `cargo test -p test_kms_server test_<name>` passes - [ ] Row added to `crate/test_kms_server/README.md` + total count updated
View on GitHub