Skip to Content
TestingAserțiuni proprii

Aserțiuni proprii

Custom assertions transformă o cerință într-o comandă pe care VM harness o poate executa. Folosiți-le pentru comportament pe care suite-ul implicit mic nu îl acoperă.

Structură

Fiecare grup custom-test are nevoie de description și una sau mai multe 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 este obligatoriu atât pe grup, cât și pe fiecare assertion. on_vm selectează un ID VM într-un test environment cu mai multe VM; fără el, runner folosește primary. expected_visual indică starea dorită a capturii de ecran când visual evidence gate este activ.

Proiectați aserțiunile în jurul rezultatelor

  • Verificați un serviciu cu service_running, nu doar existența pachetului.
  • Verificați un endpoint local înainte de a testa o rută externă.
  • Folosiți file_contains pentru un fapt de configurare stabil, nu un complete-file snapshot care cade la formatare inofensivă.
  • Folosiți command_succeeds doar cu non-interactive commands deterministe.
  • Dați timeout_seconds comenzilor lungi doar când e nevoie. Executorul limitează command timeouts la 1–1.800 secunde.
  • Nu puneți credentials în commands, descriptions, expected output sau URL; aceste câmpuri pot apărea în evidence și în jurnale.

Semantica eșecului

Un type necunoscut este acceptat momentan de recipe model, dar devine error când executorul nu găsește handler. Assertions cunoscute fără required parameters pot fi eliminate la test-plan assembly cu avertisment. Înainte de a porni build-ul, validați rețeta și inspectați materialized test plan.

Dacă on_vm numește un VM care lipsește, assertion este skipped. Nu tratați skipped sau error ca verification reușit.

Exemplu 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 } ] } }

VM-name resolution depinde de test topology și de adresele descoperite. Confirmați în run evidence rendered topology și resolved command al assertion.

Pentru fiecare supported type și parametru, consultați Tipuri de aserțiuni.