Testowanie i weryfikacja aplikacji
OpenFactory ma dwie powiązane powierzchnie:
- scenariusze obrazów, które uruchamiają zbudowany artefakt i wykonują ograniczone guest assertions; oraz
- podgląd app-platform, który tworzy immutable app variants oraz workflowy UI-test i walker.
Dostępność mocno różni się między modułami app-platform. Przed użyciem przeczytaj status na każdej stronie.
Dostępność app-platform
| Temat | Aktualna granica |
|---|---|
| App Deployment | Kolejkuje źródło Git przez immutable variant pipeline; śledź asynchroniczne deployment i health evidence. |
| App UI Testing | Przechowuje i uruchamia ograniczone semantic scenarios wobec osiągalnych targets; wyniki dowodzą tylko wymienionych actions i assertions. |
| Prompt-assisted deployment | Wymaga istniejącego template Git URL; brief to provenance, nie source generation. |
| App environment variables | Encrypted storage i deployment handoff są zaimplementowane, gdy skonfigurowano wymagane keys/tokens; rotation i runtime evidence pozostają sprawą operatora. |
| Managed Databases | Tylko stub contract; żadna baza nie jest provisioned. |
| Object Storage | Tylko stub contract; żaden bucket nie jest provisioned. |
| Custom Domains | Tylko Public-DNS ownership verification; custom TLS serving/routing nie jest aktywne. |
| Checkpoints | Tylko stub identifiers; nie istnieje recoverable snapshot. |
| Observability | Manual event storage i VM allocation są realne; ingest, probes, samples, logs i dashboard są niekompletne. |
| Web IDE | Tylko stub binding; nie provisioned jest editor ani private route. |
| App Auth | Tylko stub binding; nie provisioned jest identity provider, issuer ani real token flow. |
| Templates and Remix | Tworzy app records z manifestów lub eligible source lineage; nie deployuje ani automatycznie nie tworzy declared services. |
| Autonomous Walker | Ograniczone UI discovery z ważnymi limitami coverage, authorization i side effects. |
| Walker Diffs | Porównuje stored walks i eksportuje ticket-shaped payloads; sam nie składa external tickets. |
| Walk and Fix | Tworzy fix intent; legacy live-VM patching koliduje z immutable deployment model. |
Nie włączaj stub adapter w workflow produkcyjny tylko dlatego, że jego API zwróciło success.
Scenariusze obrazów
Image tests uruchamiają się tylko gdy wybrany build/scenario je włącza i dostępna jest wymagana test infrastructure. Trzymaj te stany osobno:
- artifact construction;
- guest provisioning i boot;
- assertion execution;
- evidence finalization; oraz
- certification or publication policy.
Build może się powieść, gdy testy są disabled, pending, failed lub incomplete.
Projekt testów
Testy wbudowane
Wbudowane nazwy takie jak boot, login, packages, network i services dają baseline. Zobacz Default Tests po ich dokładne ograniczenia.
Custom assertions
Użyj Custom Assertions do observations service, port, HTTP, file, command, process i obsługiwanych GUI. Każda assertion powinna zawierać description, expected result, target, timeout i failure meaning.
Benchmarki
Benchmark catalogs to ustrukturyzowane check sets, nie compliance determinations. Dopasuj dokładny OS/version, zachowaj applicability i failures oraz przeczytaj CIS benchmark evidence.
Checklist evidence
Przy runie, który niesie decyzję, zachowaj:
- recipe, source, build, artifact, VM, scenario i run IDs;
- dokładne artifact i source digests;
- test environment i runner version;
- każdy assertion result i raw output;
- screenshots tylko tam, gdzie uzasadnione i bezpiecznie obsłużone;
- missing, skipped lub not-applicable checks;
- timestamps i terminal status; oraz
- reviewer disposition i approval dla wymienionej decyzji.
Gdy test nie przejdzie, zdiagnozuj warstwę błędu przed ponownym buildem. Duplicate build może ukryć wadę ownership, deployment, test-runner lub evidence finalization zamiast ją naprawić.