Kohandatud kontrollid

Kohandatud kontrollid muudavad nõude käsuks, mida VM harness saab käivitada. Kasutage neid käitumise jaoks, mida väike vaikimisi testikomplekt ei kata.

Struktuur

Iga custom-test grupp vajab kirjelduse ja ühte või mitut struktureeritud kontrolli:

{
  "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 nõutav nii grupil kui igal kontrollil. on_vm valib VM ID mitme VM testikeskkonnas; ilma selleta kasutab käivitaja primary. expected_visual annab kavandatud ekraanipildi oleku, kui visuaalse tõendite värav on aktiivne.

Kujundage kontrolle tulemuste ümber

• Kontrollige teenust service_running abil, mitte ainult seda, kas pakett on olemas.
• Enne välise marsruudi testimist kontrollige kohalikku endpointi.
• Kasutage file_contains ühe stabiilse konfiguratsioonifakti jaoks, mitte terve faili snapshoti, mis murdub kahjutu vorminduse tõttu.
• Kasutage command_succeeds ainult deterministlike, mitteinteraktiivsete käskudega.
• Pikadele käskudele andke timeout_seconds ainult vajadusel. Täitja piirab käskude timeouti vahemikku 1–1,800 sekundit.
• Ärge pange mandaate käskudesse, kirjeldustesse, oodatud väljundisse ega URL-idesse; need väljad võivad ilmuda tõendites ja logides.

Ebaõnnestumise semantika

Tundmatu tüüp on praegu retseptimudelis lubatud, kuid muutub error-iks, kui täitja ei leia handlerit. Tuntud kontrollid, millel puuduvad nõutavad parameetrid, võidakse testiplaani koostamisel hoiatusega välja jätta. Seetõttu valideerige retsept ja vaadake materialiseeritud testiplaan üle enne buildi alustamist.

Kui on_vm nimetab VM-i, mida pole, on kontroll skipped. Ärge käsitlege skipped ega error eduka verifikatsioonina.

Mitme VM näide

{
  "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 nime lahendamine sõltub testitopoloogiast ja selle avastatud aadressidest. Kinnitage renderdatud topoloogia ja kontrolli lahendatud käsk jooksu tõendites.

Iga toetatud tüübi ja parameetri kohta vaadake Kontrollide tüübid.