Asserzioni personalizzate

Le asserzioni personalizzate trasformano un requisito in un comando che l’harness VM può eseguire. Usale per comportamento che la piccola suite default non copre.

Struttura

Ogni gruppo custom-test ha bisogno di una descrizione e una o più asserzioni strutturate:

{
  "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 è richiesta sia sul gruppo sia su ogni asserzione. on_vm seleziona un ID VM in un ambiente test multi-VM; senza di esso il runner usa primary. expected_visual fornisce lo stato screenshot previsto quando il gate evidenza visiva è attivo.

Progetta asserzioni attorno agli esiti

• Controlla un servizio con service_running, non solo che il suo pacchetto esista.
• Controlla un endpoint locale prima di testare una route esterna.
• Usa file_contains per un fatto configurazione stabile, non uno snapshot file completo che si rompe su formattazione innocua.
• Usa command_succeeds solo con comandi deterministici e non interattivi.
• Dai a comandi lunghi timeout_seconds solo quando serve. L’executor limita timeout comando a 1–1.800 secondi.
• Non mettere credenziali in comandi, descrizioni, output atteso o URL; questi campi possono comparire in evidenza e log.

Semantica fallimento

Un tipo sconosciuto è attualmente accettato dal modello ricetta ma diventa error quando l’executor non trova un handler. Asserzioni note che omettono parametri richiesti possono essere scartate durante assembly piano test con warning. Quindi valida la ricetta e ispeziona il piano test materializzato prima di avviare una build.

Se on_vm nomina una VM assente, l’asserzione è skipped. Non trattare skipped o error come verifica riuscita.

Esempio multi-VM

{
  "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 }
    ]
  }
}

La risoluzione nome VM dipende dalla topologia test e dai suoi indirizzi scoperti. Conferma topologia renderizzata e comando risolto dell’asserzione nell’evidenza run.

Per ogni tipo e parametro supportati, vedi Tipi asserzione.