Mukautetut väittämät

Custom assertions muuttavat vaatimuksen komennoksi, jonka VM-harness voi suorittaa. Käytä niitä käyttäytymiseen, jota pieni oletussuite ei kata.

Rakenne

Jokainen custom-test group tarvitsee description-kentän ja yhden tai useamman structured assertions -osion:

{
  "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 on pakollinen sekä groupissa että jokaisessa assertionissa. on_vm valitsee VM-tunnuksen multi-VM test environment -ympäristössä; ilman sitä runner käyttää primary-arvoa. expected_visual kertoo tarkoitetun screenshot staten, kun visual evidence gate on aktiivinen.

Suunnittele väittämät tulosten ympärille

• Tarkista palvelu service_running-tyypillä, älä vain että paketti on asennettu.
• Tarkista paikallinen endpoint ennen ulkoisen reitin testausta.
• Käytä file_contains yhteen vakaaseen konfiguraatiotietoon, älä complete-file snapshotiin, joka hajoaa harmittomasta muotoilusta.
• Käytä command_succeeds vain deterministisillä, non-interactive commands -komennoilla.
• Anna pitkille commands-komennoille timeout_seconds vain tarvittaessa. Executor rajoittaa command timeouts -arvot välille 1–1.800 sekuntia.
• Älä koskaan laita credentials-tietoja commands-, descriptions-, expected output- tai URL-kenttiin; ne voivat näkyä evidencessä ja lokeissa.

Epäonnistumisen semantiikka

Unknown type hyväksytään toistaiseksi recipe modelissa, mutta siitä tulee error, kun executor ei löydä handleria. Tunnetut assertions, joista puuttuu required parameters, voidaan pudottaa test-plan assembly -vaiheessa varoituksella. Validoi siis resepti ja tarkista materialized test plan ennen buildin käynnistämistä.

Jos on_vm nimeää VM:n, jota ei ole, assertion on skipped. Älä tulkitse skipped- tai error-tilaa onnistuneeksi verificationiksi.

Multi-VM-esimerkki

{
  "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 riippuu test topology -rakenteesta ja sen discovered addresses -arvoista. Varmista rendered topology ja assertionin resolved command run evidence -tiedoista.

Jokaiselle supported type -tyypille ja parametrille, katso Väittämien tyypit.