# kompat-testkorpus Specification ## Purpose Der Kompatibilitäts-Testkorpus hält das Sollverhalten des Dialekts als ausführbare Spezifikation fest: Referenzprogramme mit byte-genau dokumentierter Ausgabe, gegen die Frontend und (ab Phase 2) Laufzeit geprüft werden. ## Requirements ### Requirement: Korpusdateien mit byte-genauer Sollausgabe Jedes Korpusprogramm `tests/compat/.bas` SHALL eine `.out` mit dem exakten Sollzustand des Bildschirms besitzen (UTF-8, LF-Zeilenenden). Die Sollausgabe SHALL den Zellenpuffer als Textbild abbilden, getrimmt bis zur letzten belegten Zeile und Spalte; nachgestellte Leerzeichen innerhalb einer Zeile sind signifikant — `PRINT` gibt Zahlen mit führendem Vorzeichen-/Leerzeichen und nachgestelltem Leerzeichen aus. Verwendet ein Programm `COLOR`, SHALL die Sollausgabe zusätzlich eine Attributebene gleicher Abmessung enthalten; ohne `COLOR` MUST sie entfallen. `.gitattributes` MUST die `.out`-Dateien vor Zeilenenden-Konvertierung schützen. #### Scenario: Zahlformatierung in der Sollausgabe - **WHEN** ein Korpusprogramm `PRINT 1; 2; 3` enthält - **THEN** lautet die Sollzeile ` 1 2 3 ` (mit nachgestelltem Leerzeichen) #### Scenario: Getrimmter Snapshot - **WHEN** ein Korpusprogramm nur zwei Zeilen ausgibt - **THEN** umfasst die Sollausgabe genau diese zwei Zeilen und keine leeren Folgezeilen #### Scenario: Attributebene nur bei COLOR - **WHEN** ein Korpusprogramm ohne `COLOR` läuft - **THEN** enthält seine `.out` keine Attributebene ### Requirement: Frontend-Meilenstein über den Korpus Ein automatischer Test SHALL alle `tests/compat/*.bas` durch das Sprach-Frontend führen und fehlschlagen, sobald eine Datei Diagnosen liefert. (Ab Phase 2 kommt der Laufzeitvergleich `tbc run` ↔ `.out` hinzu.) #### Scenario: Korpus bleibt kompilierbar - **WHEN** die Frontend-Testsuite läuft - **THEN** parsen alle Korpusdateien diagnose-frei und der Test nennt andernfalls Datei und Diagnose ### Requirement: Laufzeitvergleich über den Korpus Ein automatischer Test SHALL jede Korpusdatei `tests/compat/*.bas` kompilieren, über die VM mit einem Host ohne Terminal ausführen und den resultierenden Bildschirmzustand gegen die zugehörige `.out`-Datei vergleichen — getrimmt, mit signifikanten Leerzeichen innerhalb der Zeilen und, sofern vorhanden, einschließlich der Attributebene. Bei Abweichung MUST der Test Datei, erste abweichende Zeile sowie Soll und Ist nennen; weicht nur die Attributebene ab, MUST er Zeile, Spalte, Soll- und Ist-Attribut nennen. #### Scenario: Korpus läuft mit korrekter Ausgabe - **WHEN** die Laufzeit-Testsuite läuft - **THEN** stimmt der Bildschirmzustand jeder Korpusdatei mit ihrer `.out` überein #### Scenario: Abweichung wird benannt - **WHEN** ein Korpusprogramm eine abweichende Ausgabe erzeugt - **THEN** schlägt der Test fehl und nennt Datei, Zeilennummer, Soll- und Ist-Zeile #### Scenario: Abweichendes Farbattribut - **WHEN** ein Korpusprogramm dasselbe Textbild, aber ein abweichendes Attribut erzeugt - **THEN** schlägt der Test fehl und nennt Zeile, Spalte, Soll- und Ist-Attribut ### Requirement: Korpusabdeckung der Phase-2-Semantik Der Korpus SHALL um Referenzprogramme mit dokumentierter Sollausgabe für die Zahlenkonvertierungs-Matrix (Rundung, Ganzzahldivision, logische Operatoren, Überlauf-Randfälle über Fehlerbehandlung), die Fehlerbehandlung (`ON ERROR`, `RESUME`-Varianten, `ERR`/`ERL`) sowie Prozeduraufrufe mit BYREF-/BYVAL-Wirkung erweitert werden. #### Scenario: Konvertierungsmatrix als Korpustest - **WHEN** die Laufzeit-Testsuite läuft - **THEN** existiert ein Korpusprogramm, das die Matrix-Randfälle ausgibt, und seine Ausgabe entspricht der dokumentierten Sollausgabe ### Requirement: Korpusabdeckung der Phase-3-Semantik Der Korpus SHALL um Referenzprogramme mit dokumentierter Sollausgabe für die Bildschirmsteuerung (`LOCATE`, `COLOR`, `CLS`, `VIEW PRINT`-Scrollen, `CSRLIN`/`POS`, Zurücklesen per `SCREEN`), die Formatierung (`PRINT USING` inklusive Feldüberlauf), breite Unicode-Zeichen (Doppelzellen, Umbruch am rechten Rand), Datum und Zeit sowie die Datei-E/A in allen drei Zugriffsarten erweitert werden. Dateiprogramme MUST in einem temporären Arbeitsverzeichnis laufen und dürfen keine Artefakte im Projektbaum hinterlassen. #### Scenario: Bildschirmsteuerung als Korpustest - **WHEN** die Testsuite läuft - **THEN** existiert ein Korpusprogramm, das mit `LOCATE` und `COLOR` an definierten Positionen ausgibt, und sein Snapshot entspricht der Sollausgabe #### Scenario: Datei-Korpustest hinterlässt nichts - **WHEN** ein Datei-E/A-Korpusprogramm gelaufen ist - **THEN** ist das Arbeitsverzeichnis wieder entfernt und der Projektbaum unverändert ### Requirement: Nachweis der Größenunabhängigkeit Die Bildschirmgröße des Test-Hosts SHALL je Korpusprogramm explizit festgelegt und in der Sollausgabe vermerkt sein; ein Vorgabewert MUST NOT stillschweigend gelten. Mindestens ein Korpusprogramm SHALL bei zwei verschiedenen Bildschirmgrößen laufen und je Größe eine eigene Sollausgabe besitzen, um nachzuweisen, dass Löschen, Umbruch, Scrollen und Cursorgrenzen der jeweiligen Größe folgen. Mindestens ein Korpusprogramm SHALL eine Größenänderung während der Ausführung durchlaufen und danach die neuen Grenzen ausnutzen. #### Scenario: Gleiches Programm bei zwei Größen - **WHEN** dasselbe Bildschirm-Korpusprogramm bei 80×25 und bei 120×40 läuft - **THEN** stimmt jede Ausgabe mit der Sollausgabe ihrer Größe überein und die Sollausgaben unterscheiden sich in Umbruch- und Scrollverhalten #### Scenario: Größenänderung mitten im Programm - **WHEN** der Test-Host während der Ausführung von 80×25 auf 120×40 wechselt - **THEN** bleibt der bisherige Inhalt oben links erhalten und die anschließende Ausgabe nutzt die neuen Grenzen ### Requirement: Korpusabdeckung der Ereignis-Traps Der Testkorpus SHALL die Ereignissteuerung mit Programmen abdecken, die ohne echte Wartezeit und mit reproduzierbarer Ausgabe laufen: Zeit-Trap, Tasten-Trap einschließlich der Frage, ob die Taste im Eingabestrom verbleibt, benutzerdefiniertes Ereignis, die drei Maskierungszustände je Quelle, der Hauptschalter `EVENT` sowie Rückkehr und Nicht-Wiedereintritt 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. #### 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 #### Scenario: Fehlende Zeitdeklaration - **WHEN** ein Korpusprogramm zeitgesteuerte Traps nutzt, aber keinen Zeitverlauf deklariert - **THEN** schlägt der Harness mit einer Meldung fehl, die die fehlende Deklaration nennt ### Requirement: Korpusabdeckung der Formularprogramme Der Testkorpus SHALL Formularprogramme mit byte-genauer Bildschirm-Sollausgabe führen. Ihre Ereignisfolge (Tasten, Maus, Zeit) SHALL im Programmkopf deklariert und vom Harness eingespeist werden, sodass ein Lauf ohne Terminal und ohne Wartezeit auskommt und zweimal 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. #### Scenario: Formularprogramm im Korpus - **WHEN** ein Formular-Korpusprogramm mit deklarierter Ereignisfolge ausgeführt wird - **THEN** entspricht der Bildschirminhalt byte-genau der Sollausgabe #### Scenario: Wiederholbarkeit - **WHEN** dasselbe Programm zweimal ausgeführt wird - **THEN** ist die Ausgabe beide Male identisch ### 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. #### Scenario: Fremdprogramm übersetzt - **WHEN** ein Formularprogramm des öffentlichen Bestands übersetzt wird - **THEN** entstehen keine Diagnosen und das Programm ist bedienbar