Brugerdefinerede assertions

Custom assertions gør et krav om til en kommando, som VM-harnessen kan køre. Brug dem til adfærd, som den lille standardsuite ikke dækker.

Struktur

Hver custom-test group skal have description og en eller flere 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 er påkrævet både på group og på hver assertion. on_vm vælger et VM-ID i et multi-VM test environment; uden det bruger runneren primary. expected_visual angiver den tilsigtede screenshot state, når visual evidence gate er aktiv.

Design assertions omkring resultater

• Tjek en service med service_running, ikke blot at pakken findes.
• Tjek et lokalt endpoint, før du tester en ekstern route.
• Brug file_contains til ét stabilt konfigurationsfaktum, ikke en complete-file snapshot, der fejler ved harmløs formatering.
• Brug command_succeeds kun med deterministiske, non-interactive commands.
• Giv lange commands timeout_seconds kun når det er nødvendigt. Executoren begrænser command timeouts til 1–1.800 sekunder.
• Læg aldrig credentials i commands, descriptions, expected output eller URL; disse felter kan vises i evidence og logs.

Fejlsemantik

En unknown type accepteres i øjeblikket af recipe model, men bliver error, når executoren ikke finder en handler. Kendte assertions uden required parameters kan fjernes under test-plan assembly med en advarsel. Valider derfor opskriften, og gennemgå materialized test plan, før du starter en build.

Hvis on_vm navngiver en VM, der ikke findes, er assertionen skipped. Betragt ikke skipped eller error som vellykket verification.

Multi-VM-eksempel

{
  "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 afhænger af test topology og dens discovered addresses. Bekræft rendered topology og assertionens resolved command i run evidence.

For hver supported type og parameter, se Assertion-typer.