Eigene Assertions

Custom assertions machen aus einer Anforderung einen Befehl, den der VM-Harness ausführen kann. Nutzen Sie sie für Verhalten, das die kleine Default-Suite nicht abdeckt.

Struktur

Jede custom-test group braucht description und eine oder mehrere structured assertions:

{
  "description": "Verify the web service",
  "category": "application",
  "assertions": [
    {
      "type": "service_running",
      "description": "Nginx is active",
      "params": { "service": "nginx" },
      "expected_visual": "The evidence panel shows nginx active"
    },
    {
      "type": "http_responds",
      "description": "Local health endpoint responds",
      "params": { "url": "http://localhost/health", "status": 200 }
    }
  ]
}

description ist auf group und jeder assertion required. on_vm wählt eine VM-ID in multi-VM test environment; ohne es nutzt der Runner primary. expected_visual liefert intended screenshot state, wenn visual evidence gate aktiv ist.

Assertions um Outcomes entwerfen

• Dienst mit service_running prüfen, nicht nur Paketexistenz.
• Lokalen Endpoint prüfen, bevor externe Route getestet wird.
• file_contains für einen stabilen Config-Fakt, kein Complete-File-Snapshot, der an harmloser Formatierung bricht.
• command_succeeds nur mit deterministischen, non-interactive commands.
• Langen Befehlen timeout_seconds nur wenn nötig. Executor clamped command timeouts auf 1–1.800 Sekunden.
• Keine Credentials in commands, descriptions, expected output oder URLs; diese Felder können in Evidenz und Logs erscheinen.

Failure-Semantik

Unbekannter type wird derzeit vom recipe model akzeptiert, wird aber error, wenn der Executor keinen handler findet. Bekannte assertions ohne required parameters können bei test-plan assembly mit warning gedroppt werden. Rezept validieren und materialized test plan inspizieren vor Build-Start.

Nennt on_vm eine VM, die nicht present ist, ist die assertion skipped. Behandeln Sie skipped oder error nicht als successful verification.

Multi-VM-Beispiel

{
  "description": "Client reaches the API node",
  "assertions": [
    {
      "type": "http_responds",
      "description": "API health is reachable from the client",
      "on_vm": "client",
      "params": { "url": "http://api:8080/health", "status": 200 }
    }
  ],
  "environment": {
    "vms": [
      { "vm_id": "client", "role": "client", "networks": ["lan"] },
      { "vm_id": "api", "role": "server", "networks": ["lan"] }
    ],
    "networks": [
      { "network_id": "lan", "type": "isolated", "dhcp": true }
    ]
  }
}

VM-name resolution hängt von test topology und discovered addresses ab. Rendered topology und resolved command der assertion in run evidence bestätigen.

Für jeden supported type und parameter siehe Assertion types.