Testing und Application Verification
OpenFactory hat zwei verwandte Oberflächen:
- Image-Szenarien, die ein gebautes Artefakt booten und begrenzte Gast-Assertions ausführen; und
- eine App-Platform-Preview, die immutable app variants plus UI-Test- und Walker-Workflows erzeugt.
Verfügbarkeit unterscheidet sich stark über App-Platform-Module. Status auf jeder Seite lesen vor Nutzung.
App-Platform-Verfügbarkeit
| Thema | Aktuelle Grenze |
|---|---|
| App Deployment | Queued Git source durch immutable variant pipeline; asynchrones Deployment und Health-Nachweis verfolgen. |
| App UI Testing | Speichert und führt begrenzte semantic scenarios gegen erreichbare Targets aus; Ergebnisse beweisen nur stated actions und assertions. |
| Prompt-assisted deployment | Braucht bestehende template Git URL; das Brief ist Provenienz, keine Source-Generierung. |
| App environment variables | Encrypted storage und deployment handoff implementiert, wenn required keys/tokens konfiguriert; Rotation und runtime evidence bleiben Operator-Themen. |
| Managed Databases | Nur Stub contract; keine Database provisioned. |
| Object Storage | Nur Stub contract; kein Bucket provisioned. |
| Custom Domains | Nur Public-DNS ownership verification; custom TLS serving/routing nicht aktiv. |
| Checkpoints | Nur Stub identifiers; kein recoverable snapshot. |
| Observability | Manual event storage und VM allocation real; ingest, probes, samples, logs und dashboard incomplete. |
| Web IDE | Nur Stub binding; kein Editor oder private route provisioned. |
| App Auth | Nur Stub binding; kein identity provider, issuer oder real token flow provisioned. |
| Templates and Remix | Erzeugt app records aus manifests oder eligible source lineage; deployt nicht und erzeugt declared services nicht automatisch. |
| Autonomous Walker | Begrenzte UI discovery mit wichtigen Coverage-, Authorization- und Side-Effect-Limits. |
| Walker Diffs | Vergleicht stored walks und exportiert ticket-shaped payloads; filed keine external tickets selbst. |
| Walk and Fix | Erzeugt fix intent; legacy live-VM patching kollidiert mit immutable deployment model. |
Verketten Sie keinen stub adapter in einen Produktions-Workflow, weil seine API success zurückgab.
Image-Szenarien
Image-Tests laufen nur, wenn gewählter Build/Szenario sie aktiviert und required test infrastructure verfügbar ist. Diese Zustände getrennt halten:
- Artefakt-Konstruktion;
- Gast-Provisioning und Boot;
- Assertion-Ausführung;
- Evidenz-Finalisierung; und
- Zertifizierungs- oder Publikations-Policy.
Ein Build kann succeed während Tests disabled, pending, failed oder incomplete sind.
Test-Design
Built-in tests
Built-in names wie boot, login, packages, network und services liefern Baseline.
Default Tests für ihre exakten Grenzen inspizieren.
Custom assertions
Eigene Assertions für Service-, Port-, HTTP-, File-, Command-, Process- und supported GUI observations. Jede Assertion soll description, expected result, target, timeout und failure meaning haben.
Benchmarks
Benchmark-Kataloge sind strukturierte Check-Sets, keine Compliance-Determinations. Exaktes OS/Version matchen, applicability und failures behalten, CIS-Benchmark-Nachweis lesen.
Evidenz-Checkliste
Für einen decision-bearing run behalten:
- Rezept-, Source-, Build-, Artefakt-, VM-, Szenario- und Run-IDs;
- exakte Artefakt- und Source-Digests;
- Test-Umgebung und Runner-Version;
- jedes Assertion-Ergebnis und raw output;
- Screenshots nur wo gerechtfertigt und sicher behandelt;
- missing, skipped oder not-applicable checks;
- Timestamps und terminal status; und
- Reviewer disposition und approval für die stated decision.
Schlägt ein Test fehl, failing layer diagnostizieren vor rebuild. Duplicate build kann ownership-, deployment-, test-runner- oder evidence-finalization defect verbergen statt zu fixen.