Niestandardowe asercje

Custom assertions zamieniają wymaganie w polecenie, które VM harness może wykonać. Używaj ich dla zachowania, którego mała domyślna suite nie obejmuje.

Struktura

Każda custom-test group potrzebuje description oraz jednej lub więcej 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 jest wymagane zarówno na group, jak i na każdej assertion. on_vm wybiera VM ID w multi-VM test environment; bez tego runner używa primary. expected_visual podaje zamierzony screenshot state, gdy visual evidence gate jest aktywna.

Projektuj asercje wokół wyników

• Sprawdzaj service przez service_running, a nie tylko to, że pakiet istnieje.
• Sprawdź lokalny endpoint przed testem trasy zewnętrznej.
• Używaj file_contains dla jednego stabilnego faktu konfiguracyjnego, nie complete-file snapshot, który psuje się przy nieszkodliwym formatowaniu.
• Używaj command_succeeds tylko z deterministycznymi, non-interactive commands.
• Nadawaj długim commands timeout_seconds tylko gdy trzeba. Executor ogranicza command timeouts do 1–1.800 sekund.
• Nigdy nie umieszczaj credentials w commands, descriptions, expected output ani URL; te pola mogą trafić do evidence i logów.

Semantyka niepowodzenia

Unknown type jest obecnie akceptowany przez recipe model, ale staje się error, gdy executor nie znajdzie handler. Znane assertions bez required parameters mogą zostać odrzucone podczas test-plan assembly z ostrzeżeniem. Zwaliduj więc recepturę i sprawdź materialized test plan przed uruchomieniem build.

Jeśli on_vm wskazuje VM, której nie ma, assertion ma status skipped. Nie traktuj skipped ani error jako udanego verification.

Przykład 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 zależy od test topology i discovered addresses. Potwierdź rendered topology oraz resolved command assertion w run evidence.

Dla każdego supported type i parametru zobacz Typy asercji.