Тестування та верифікація застосунків
OpenFactory має two related surfaces:
- image scenarios that boot built artifact and run bounded guest assertions; and
- app-platform preview that creates immutable app variants plus UI-test and walker workflows.
Availability differs substantially across app-platform modules. Read status on each page before using.
App-platform availability
| Topic | Current boundary |
|---|---|
| App Deployment | Queues Git source through immutable variant pipeline; follow asynchronous deployment and health evidence. |
| App UI Testing | Stores and runs bounded semantic scenarios against reachable targets; results prove only stated actions and assertions. |
| Prompt-assisted deployment | Requires existing template Git URL; brief is provenance, not source generation. |
| App environment variables | Encrypted storage and deployment handoff implemented when required keys/tokens configured; rotation and runtime evidence remain operator concerns. |
| Managed Databases | Stub contract only; no database provisioned. |
| Object Storage | Stub contract only; no bucket provisioned. |
| Custom Domains | Public-DNS ownership verification only; custom TLS serving/routing not active. |
| Checkpoints | Stub identifiers only; no recoverable snapshot exists. |
| Observability | Manual event storage and VM allocation real; ingest, probes, samples, logs, dashboard incomplete. |
| Web IDE | Stub binding only; no editor or private route provisioned. |
| App Auth | Stub binding only; no identity provider, issuer, or real token flow provisioned. |
| Templates and Remix | Creates app records from manifests or eligible source lineage; does not deploy or automatically create declared services. |
| Autonomous Walker | Bounded UI discovery with important coverage, authorization, side-effect limits. |
| Walker Diffs | Compares stored walks and exports ticket-shaped payloads; does not file external tickets by itself. |
| Walk and Fix | Creates fix intent; legacy live-VM patching conflicts with immutable deployment model. |
Do not chain stub adapter into production workflow because API returned success.
Image scenarios
Image tests run only when selected build/scenario enables them and required test infrastructure available. Keep these states separate:
- artifact construction;
- guest provisioning and boot;
- assertion execution;
- evidence finalization; and
- certification or publication policy.
Build can succeed while tests disabled, pending, failed, or incomplete.
Test design
Built-in tests
Built-in names such as boot, login, packages, network, services provide baseline. Inspect Default Tests for precise limitations.
Custom assertions
Use Custom Assertions for service, port, HTTP, file, command, process, supported GUI observations. Every assertion should include description, expected result, target, timeout, failure meaning.
Benchmarks
Benchmark catalogs are structured check sets, not compliance determinations. Match exact OS/version, retain applicability and failures, read CIS benchmark evidence.
Evidence checklist
For decision-bearing run, retain:
- recipe, source, build, artifact, VM, scenario, run IDs;
- exact artifact and source digests;
- test environment and runner version;
- every assertion result and raw output;
- screenshots only where justified and safely handled;
- missing, skipped, not-applicable checks;
- timestamps and terminal status; and
- reviewer disposition and approval for stated decision.
When test fails, diagnose failing layer before rebuilding. Duplicate build can hide ownership, deployment, test-runner, or evidence-finalization defect rather than fixing it.