Spezifikationsabgleich und Regressionsnachweise abschließen
This commit is contained in:
@@ -29,19 +29,32 @@ abgewiesen werden.
|
||||
- **THEN** wird sie abgewiesen und die Meldung nennt `3.00`
|
||||
|
||||
### Requirement: Schreiben ist die Umkehrung des Lesens
|
||||
Das Schreiben einer gelesenen Formularbeschreibung SHALL dieselbe Datei
|
||||
ergeben. Geschrieben SHALL nur werden, was vom Vorgabewert abweicht;
|
||||
Reihenfolge und Einrückung SHALL festgelegt und dokumentiert sein, damit
|
||||
zwei Läufe dieselbe Datei erzeugen.
|
||||
Das unveränderte Schreiben einer gelesenen Formularbeschreibung SHALL
|
||||
die Originaldatei bytegleich erhalten, einschließlich explizit
|
||||
geschriebener Vorgabewerte. Beim kanonischen Schreiben einer neuen oder
|
||||
geänderten Beschreibung SHALL nur geschrieben werden, was vom
|
||||
Vorgabewert abweicht. Für diese kanonische Ausgabe SHALL Reihenfolge
|
||||
und Einrückung festgelegt und dokumentiert sein, damit zwei Läufe
|
||||
dieselbe Datei erzeugen. Ein expliziter Control-Array-Index SHALL auch bei
|
||||
`Index = 0` erhalten bleiben; er ist eine Strukturangabe und kein auslassbarer
|
||||
Eigenschaftsdefault.
|
||||
|
||||
#### Scenario: Rundlauf
|
||||
- **WHEN** eine Formulardatei gelesen und unverändert wieder geschrieben wird
|
||||
- **THEN** ist die geschriebene Datei byte-gleich zur gelesenen
|
||||
|
||||
#### Scenario: Vorgabewerte werden nicht geschrieben
|
||||
- **WHEN** ein Steuerelement nur Vorgabewerte trägt
|
||||
- **WHEN** eine neue oder geänderte Beschreibung kanonisch geschrieben wird und ein Steuerelement nur Vorgabewerte trägt
|
||||
- **THEN** enthält sein Block außer `Begin`/`End` keine Eigenschaftszeile
|
||||
|
||||
#### Scenario: Expliziter Default im unveränderten Original
|
||||
- **WHEN** eine gelesene Datei einen Vorgabewert ausdrücklich enthält und unverändert geschrieben wird
|
||||
- **THEN** bleibt auch diese Eigenschaftszeile bytegleich erhalten
|
||||
|
||||
#### Scenario: Arrayelement mit Index null
|
||||
- **WHEN** ein Formular mit einem einzigen Control-Arrayelement `Index = 0` kanonisch geschrieben und erneut gelesen wird
|
||||
- **THEN** bleibt das Control ein Array und seine Indexangabe erhalten
|
||||
|
||||
### Requirement: Fehlerhafte Dateien werden benannt
|
||||
Eine unbekannte Klasse, eine für die Klasse unbekannte Eigenschaft, ein
|
||||
Wert außerhalb des Wertebereichs und ein unausgeglichener Block MUST je
|
||||
|
||||
@@ -121,6 +121,8 @@ eines Handlers. Ein Korpusprogramm mit Zeitbezug SHALL seinen
|
||||
Zeitverlauf im Programmkopf deklarieren; ohne Deklaration MUST der
|
||||
Harness den Lauf abweisen statt auf die Systemuhr auszuweichen.
|
||||
|
||||
Die drei Zustände SHALL für KEY und UEVENT ebenso ausdrücklich im Korpus vorkommen wie für TIMER, einschließlich der Lesbarkeit einer unter KEY STOP gemerkten Taste.
|
||||
|
||||
#### Scenario: Zeit-Trap im Korpus
|
||||
- **WHEN** ein Korpusprogramm mit deklariertem Zeitverlauf und `ON TIMER` ausgeführt wird
|
||||
- **THEN** entspricht der Bildschirminhalt byte-genau der Sollausgabe und der Lauf benötigt keine messbare Wartezeit
|
||||
@@ -129,6 +131,10 @@ Harness den Lauf abweisen statt auf die Systemuhr auszuweichen.
|
||||
- **WHEN** ein Korpusprogramm zeitgesteuerte Traps nutzt, aber keinen Zeitverlauf deklariert
|
||||
- **THEN** schlägt der Harness mit einer Meldung fehl, die die fehlende Deklaration nennt
|
||||
|
||||
#### Scenario: KEY STOP im Korpus
|
||||
- **WHEN** der Korpus einen F1-Druck unter KEY STOP und ein späteres ON ausführt
|
||||
- **THEN** prüft seine Sollausgabe sowohl die normal lesbare Taste als auch genau eine spätere Handlerausführung
|
||||
|
||||
### Requirement: Korpusabdeckung der Formularprogramme
|
||||
Der Testkorpus SHALL Formularprogramme mit byte-genauer
|
||||
Bildschirm-Sollausgabe führen. Ihre Ereignisfolge (Tasten, Maus, Zeit)
|
||||
@@ -138,6 +144,8 @@ dasselbe Ergebnis liefert. Abgedeckt SHALL sein: Fokus- und
|
||||
Tabreihenfolge, Access-Key, Klick über die Maus, Menüauswahl, ein
|
||||
Listen-Steuerelement, ein Timer und ein modaler Dialog.
|
||||
|
||||
Der Access-Key-Nachweis SHALL mindestens ein gewöhnliches Control betreffen und MUST NOT allein durch einen Menü-Access-Key ersetzt werden. Rückwärtstab und die beobachtbare Reihenfolge LostFocus vor GotFocus SHALL enthalten sein.
|
||||
|
||||
#### Scenario: Formularprogramm im Korpus
|
||||
- **WHEN** ein Formular-Korpusprogramm mit deklarierter Ereignisfolge ausgeführt wird
|
||||
- **THEN** entspricht der Bildschirminhalt byte-genau der Sollausgabe
|
||||
@@ -146,12 +154,22 @@ Listen-Steuerelement, ein Timer und ein modaler Dialog.
|
||||
- **WHEN** dasselbe Programm zweimal ausgeführt wird
|
||||
- **THEN** ist die Ausgabe beide Male identisch
|
||||
|
||||
#### Scenario: Control-Access-Key und Rückwärtstab
|
||||
- **WHEN** ein Formular-Korpus Alt+O für eine OK-Schaltfläche und anschließend Rückwärtstab deklariert
|
||||
- **THEN** weist die Sollausgabe den Click und den Fokuswechsel in korrekter Reihenfolge nach
|
||||
|
||||
### Requirement: Kompatibilitätsnachweis an Fremdprogrammen
|
||||
Die Formularprogramme aus dem öffentlichen Bestand des Vorbilds SHALL
|
||||
sich ohne Diagnosen oder Non-Features übersetzen lassen und bedienbar
|
||||
sein. Jeder entdeckte fehlende Sprach-, Projekt-, Formular- oder
|
||||
Laufzeitpfad MUST implementiert und als Befund festgehalten werden.
|
||||
|
||||
Der Nachweis SHALL den verwendeten öffentlichen Bestand mit Revision und Programmeinstiegen benennen sowie reproduzierbare Eingabesequenzen und sichtbare Zustandsänderungen führen. Ein bloß erfolgreiches Starten MUST NOT als Bediennachweis gelten.
|
||||
|
||||
#### Scenario: Fremdprogramm übersetzt
|
||||
- **WHEN** ein Formularprogramm des öffentlichen Bestands übersetzt wird
|
||||
- **THEN** entstehen keine Diagnosen und das Programm ist bedienbar
|
||||
|
||||
#### Scenario: Bediennachweis ist wiederholbar
|
||||
- **WHEN** ein dokumentiertes Fremdprogramm erneut mit seiner Prüfsequenz ausgeführt wird
|
||||
- **THEN** werden dieselben relevanten Formularzustände beziehungsweise Abschlussereignisse erreicht
|
||||
|
||||
@@ -84,15 +84,23 @@ Sprungziele („Label not defined") sowie Prozedur- und Builtin-Signaturen
|
||||
Die Semantik MUST jede Verwendung der in docs/sprachreferenz.md
|
||||
(„Abweichungen") deklarierten Non-Features — Hardware-Nähe (`PEEK`,
|
||||
`POKE`, `INP`, `OUT`, `WAIT`, `BLOAD`/`BSAVE`, `VARPTR`-Familie, `CALL
|
||||
ABSOLUTE`/`INTERRUPT`, `IOCTL`), `CHAIN`, Grafik-Anweisungen, `SOUND`/
|
||||
ABSOLUTE`/`INTERRUPT`, `IOCTL`), `CHAIN`, die weiterhin ausgeschlossenen Grafik-Anweisungen (`PSET`,
|
||||
`PRESET`, `CIRCLE`, `DRAW`, Grafik-`GET`/`PUT`, `PALETTE`, `WINDOW`,
|
||||
`PMAP`, `PCOPY`, `POINT`), `SOUND`/
|
||||
`PLAY` und die Event-Geräte `COM`/`PEN`/`PLAY`/`STRIG` — zur Compile-Zeit
|
||||
mit der Meldung „Feature unavailable" abweisen. Dokumentierte Features
|
||||
außerhalb dieser Liste MUST NOT abgewiesen werden (Guiding Principle).
|
||||
|
||||
Die dokumentierte Zellenpuffer-Untermenge SCREEN 0–13, LINE, PAINT und VIEW SHALL verfügbar bleiben.
|
||||
|
||||
#### Scenario: Hardware-Zugriff
|
||||
- **WHEN** `POKE 100, 1` oder `x = PEEK(100)` kompiliert wird
|
||||
- **THEN** erscheint die Compile-Diagnose „Feature unavailable"
|
||||
|
||||
#### Scenario: Erlaubte Grafikuntermenge
|
||||
- **WHEN** ein Programm SCREEN 1, LINE, PAINT und VIEW in gültiger Syntax verwendet
|
||||
- **THEN** wird es ohne Feature-unavailable-Diagnose übersetzt
|
||||
|
||||
### Requirement: Diagnostik mit Vorbild-Meldungen
|
||||
Diagnosen SHALL exakte 1-basierte Quelltextpositionen (Zeile, Spalte)
|
||||
tragen; die Meldungstexte SHALL dem Katalog des Vorbilds folgen, wo eine
|
||||
|
||||
@@ -64,6 +64,8 @@ mit „Feature unavailable" abgewiesen werden. Der Test MUST das
|
||||
divergierende Element, seinen Inventarstatus und den vorgefundenen
|
||||
Zustand benennen.
|
||||
|
||||
Klassentabellen oder deklarierte Signaturnamen allein MUST NOT als Laufzeitnachweis gelten. Für implementierte Elemente SHALL ein erreichbarer Frontend-/Absenkungspfad und ein ausführbares Laufzeitziel geprüft werden. Für deklarierte Ereignisse SHALL ein Test den Auslöser bis zum BASIC-Handler führen.
|
||||
|
||||
#### Scenario: Inventar hinkt der Implementierung hinterher
|
||||
- **WHEN** `LOCATE` implementiert wurde, im Inventar aber noch `offen` steht
|
||||
- **THEN** schlägt der Abgleich fehl und nennt `LOCATE`, Status `offen` und den Befund „implementiert"
|
||||
@@ -76,6 +78,10 @@ Zustand benennen.
|
||||
- **WHEN** der Abgleich läuft
|
||||
- **THEN** nennt er die Zahl der Einträge je Status als Abdeckungsstand
|
||||
|
||||
#### Scenario: Deklariertes Ereignis ohne Auslöser
|
||||
- **WHEN** ein als implementiert geführtes Formularereignis bei seiner dokumentierten Hosteingabe keinen Handler ausführt
|
||||
- **THEN** schlägt der Abgleich mit Name, Status und fehlendem Auslösepfad fehl
|
||||
|
||||
### Requirement: Keine stillen Lücken bei dokumentierten Elementen
|
||||
Ein Element mit Status `offen` MUST bei Verwendung eine benannte
|
||||
Ablehnung erzeugen — entweder eine Compile-Diagnose oder den Laufzeitfehler
|
||||
|
||||
Reference in New Issue
Block a user