Aangepaste assertions

Custom assertions maken van een vereiste een opdracht die de VM-harness kan uitvoeren. Gebruik ze voor gedrag dat de kleine standaardsuite niet dekt.

Structuur

Elke custom-test group heeft een description en een of meer structured assertions nodig:

{
  "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 is verplicht op zowel de group als op elke assertion. on_vm selecteert een VM-ID in een multi-VM test environment; zonder dat veld gebruikt de runner primary. expected_visual geeft de bedoelde screenshot state wanneer de visual evidence gate actief is.

Assertions rond resultaten ontwerpen

• Controleer een service met service_running, niet alleen dat het pakket bestaat.
• Controleer een lokaal endpoint voordat u een externe route test.
• Gebruik file_contains voor één stabiel configuratiefeit, geen complete-file snapshot die breekt bij onschuldige opmaak.
• Gebruik command_succeeds alleen met deterministische, non-interactive commands.
• Geef lange commands alleen timeout_seconds wanneer dat nodig is. De executor begrenst command timeouts tot 1–1.800 seconden.
• Zet nooit credentials in commands, descriptions, expected output of URLs; deze velden kunnen in evidence en logs verschijnen.

Semantiek bij falen

Een unknown type wordt momenteel door het recipe model geaccepteerd, maar wordt error wanneer de executor geen handler vindt. Bekende assertions die required parameters missen, kunnen tijdens test-plan assembly met een warning worden weggelaten. Valideer daarom het recept en inspecteer het materialized test plan voordat u een build start.

Als on_vm een VM noemt die niet aanwezig is, is de assertion skipped. Behandel skipped of error niet als geslaagde verification.

Multi-VM-voorbeeld

{
  "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 hangt af van de test topology en de discovered addresses. Bevestig de rendered topology en de resolved command van de assertion in de run evidence.

Voor elk supported type en parameter, zie Assertion-typen.