Стандартні тести

Testing enabled by default in normalized recipe, with four predefined test names: boot, login, packages, network. These are small guest checks, not complete acceptance suite. Recipe can disable testing or replace list, some artifact types use narrower contract.

What the defaults actually prove

Test	Executed check	Does not prove
`boot`	`uptime` exits successfully through QEMU guest agent	Every bootloader path, hardware boot, absence of kernel warnings
`login`	`whoami` can run through root guest-agent channel	Interactive password, SSH-key, PAM, desktop-greeter, end-user login
`packages`	One of `dpkg --list`, `rpm -qa`, or `pacman -Q` succeeds	Every package requested by prompt installed
`network`	DNS resolves `example.com` and TCP connection to port 443 succeeds after bounded retries	General internet health, HTTP content, every interface, air-gapped design

Ubuntu 24.04 CIS path removes generic network check and uses readiness-gated feature assertion instead. Recipe without expected internet route can have failed generic network check converted to warning.

Feature and capability checks

Runner also merges checks supplied by enabled feature metadata, legacy hook test files, frozen capability plan, explicit custom tests, benchmark tests. Duplicate assertions removed. Assertions with known missing parameters dropped with server warning; review resulting test plan so dropped check not mistaken for pass.

Examples include checking configured SSH port, service state, requested package, recipe-specific artifact. Coverage depends on enabled feature: inclusion of feature does not by itself guarantee complete assertion set.

Reading the result

Use assertion rows and evidence, not only aggregate badge:

passed means executable check returned expected result.
failed means check ran and contradicted expectation.
error means harness could not produce verdict.
skipped means check did not run, for example because target VM absent.

Errors and skips are not passes. Completed image and passed test run are separate states; certification is third gate.

Define stronger acceptance criteria

For real workload add prompt-relevant assertions. For example:


{
  "description": "Nginx serves the local health endpoint",
  "assertions": [
    {
      "type": "service_running",
      "description": "Nginx is active",
      "params": { "service": "nginx" }
    },
    {
      "type": "http_responds",
      "description": "Health endpoint returns 200",
      "params": { "url": "http://localhost/health", "status": 200 }
    }
  ]
}

Then inspect built image in console and, for hardware-bound claims, test on representative hardware. See Custom assertions and Assertion types.