Commit Graph

9 Commits

Author SHA1 Message Date
s.ayadi 5902343352 [CHANGE] Nur noch EIN Test baut die HundM-Geometrie: Spec wird TEST_HUNDM05
Nach dem gruenen VF_SPEC_BAU-Lauf bauten zwei Tests dieselben 5 Ketten. Der
Spec-Pfad ist jetzt der routinemaessige Bau-Test, der Aufzeichnungs-Pfad der
abgeschaltete Regressionstest fuer das Journal-Format.

Umbenennungen:
- tests/testdata/vf_spec_hundm05.json -> tests/testdata/hundm05.json
  Die Spec ist das Eingabeformat und die Datei, in der weitere Ketten der
  Anlage nachgetragen werden. spec_ids jetzt VF_hundm05_LZ_* (wie im
  Aufzeichnungs-Protokoll), damit sich die Ergebnisse beider Laeufe paaren
  lassen.
- tests/testdata/hundm05.json -> tests/testdata/hm_recformat.json
  tests/test_hundm05.lsp -> tests/test_hm_recformat.lsp (TEST_HM_RECFORMAT,
  Praefix hmrec:, Export hm_recformat:export-results)
  tests/test_hundm05.py -> tests/test_hm_recformat.py
  In alltests.json auf "disabled": true.

Neu: tests/test_hundm05.lsp (TEST_HUNDM05) baut die Spec - OHNE eigene
Bau-Logik, es ruft vsp-bau-datei aus Lisp/vf_spec.lsp. Damit gibt es genau
einen Code-Pfad, der aus einer Spec Geometrie erzeugt; c:VF_SPEC_BAU nutzt
denselben. tests/test_hundm05.py prueft das Ergebnis (die 9 Tests, die
vorher in test_vf_spec.py standen); test_vf_spec.py ist jetzt reiner
Uebersetzer-Test ohne CAD.

Warum das Aufzeichnungsformat bleibt (Details in
doc/TODO-plan-vf-interactive.md Abschnitt 4.7):
- hm_recformat.json ist die EINZIGE eingecheckte Kopie der Originaldaten
  (data/polylines.dxf ist mit 124 MB per .gitignore ausgeschlossen). Die Spec
  ist daraus abgeleitet; ohne die Aufzeichnung faellt die rechte Seite des
  Rundlauf-Beweises weg.
- Es prueft eine ANDERE Invariante: das Journal kommt roh aus der XDATA einer
  Kundenzeichnung. TEST_HM_RECFORMAT ist damit der einzige Test dafuer, dass
  ein BESTEHENDER VF_n-Block weiter abspielbar ist - also dass
  Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Ein
  spec-gebautes Journal kann das nicht zeigen, es kommt aus dem Uebersetzer.
- Es dokumentiert die Frage-Reihenfolge (kommentar je Eintrag); die Spec
  verbirgt den Dialog, das ist ihr Zweck.

Weitere Anpassungen:
- Ergebnisdatei heisst nach der Spec-Datei (<basisname>_results.json), damit
  Befehl und Testrunner in dieselbe Datei schreiben. Verzeichnis: tests/output
  (Override DXFM_VF_SPEC_OUT); NICHT DXFM_RESULTS - das sind die Sivas-/
  CSV-Exporte, dort landete die Datei ausserhalb des Testbaums.
- Neu *vsp-dim-override* fuer TEST_HUNDM05_2D/_3D: wird je Kette angewandt,
  weil der Abbruch-Handler in vf-linienzug-modus *ssg-ils-dim* zurueck setzt.
- Das Anlagenkuerzel der test_id in lib/vf_journal_export.py kam aus dem
  Namen der Ziel-JSON. Nach der Umbenennung haette eine Regenerierung die ids
  stillschweigend auf VF_hm_recformat_LZ_* geaendert und die Paarung der
  beiden Laeufe zerlegt - jetzt feste Konstante TEST_ID_ANLAGE.
- conftest: hundm05_* Fixtures -> hmrec_* (die Spec-Fixtures stehen in
  tests/test_hundm05.py).

Verifiziert: 98 pytest-Tests gruen (die 9 Ergebnis-Tests warten auf einen
neuen TEST_HUNDM05-Lauf), alle .lsp lint-sauber, Spec-Regenerierung
idempotent, TEST_VF_SPEC in BricsCAD 28 PASS / 0 FAIL.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 11:11:12 +02:00
s.ayadi 7242e815f8 HundM05-Testfall und DXF-Analyse-Skripte
- lib/dxf_scan_components.py: erkennt ILS-/Omniflo-Komponenten in fremden
  Projektzeichnungen und schreibt sie im Testdaten-JSON-Schema aus
- lib/dxf_abbild.py: getreue Abbildung der Bauteile einer Fremdzeichnung
  (Attribute, Weltkoordinaten, Unterkomponenten) ohne Interpretation
- tests/test_hundm05.{lsp,py}, testdata/hundm05.json, conftest-Fixtures und
  alltests.json-Eintrag fuer den Kreisel-Abschnitt aus ST500592_05.dxf
- menu: TEST_HUNDM05 im Testmenue, Connection_Insert/Edit in SSG_LIB.cui
- Doku: hartkodierte Pfade durch (getenv "DXFMAKRO") ersetzt

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 12:10:58 +02:00
m.stangl 2f2e7c46d9 erste Fassung der Erzeugung von Mubea als Test hinzugefügt 2026-07-27 16:04:32 +02:00
m.stangl 3869f8b624 omniflo unittest liest aktuell nur die json Exports von Bricscad 2026-07-02 14:03:55 +02:00
m.stangl 3dd6e091e0 Gefällestrecke nach dem gleichen Muster bedaten wie die anderen Tests. Eingabedaten aus dem Test in json Datei gezogen. Ergänzung des Testsfalls durch Ergänzung des testsdata/*_tests.json möglich 2026-07-02 12:43:23 +02:00
m.stangl 2e72f17806 Neue Testklassen für den Förderer gebaut: Status, Mathematik, ExportCSV und ExportSivas. Lisp/export.lsp wurde um VF_1, VF_2 Blöcke erweitert, um ein csv zu erhalten. Export_sivas und export_csv entsprechend um die nötigen Daten ergänzt 2026-06-30 11:21:06 +02:00
m.stangl bd053d76d3 Kreisel Script-Funktionen und flaches JSON-Testformat
- kreisel-insert-script und kreisel-connect-script in KreiselInsert.lsp
  fuer nicht-interaktives Einfuegen (Tests, Automatisierung)
- kreisel_tests.json von verschachteltem auf flaches JSON-Array umgestellt
  (kompatibel mit omni:load-json)
- test_kreisel.py an neues JSON-Format angepasst (direkte Felder statt
  nested expect/attributes)
- conftest.py: Leere kreisel_results.json wird jetzt korrekt uebersprungen

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-06-18 16:05:40 +02:00
m.stangl 041d292681 Omniflo-Testsuite hinzugefuegt (Python + AutoLISP)
tests/test_omniflo.py (350 Zeilen):
  Python-Tests fuer den Omniflo Bogen/Weiche Export. Testet:
  - Unit-Tests fuer build_bogen_merkmale / build_weiche_merkmale gegen
    Testdefinitionen aus omniflo_tests.json (kein BricsCAD erforderlich)
  - Merkmale-Werte gegen den JSON-Katalog (omniflo_boegen/weichen.json)
  - Korrekte Anzahl und Reihenfolge der Elemente in process_blocks()
  - CSV-Ausgabeformat (Header, Spaltenanzahl, Merkmale als JSON)
  - Integrationstest: liest eine tatsaechliche CSV aus einem BricsCAD-
    Lauf (falls DXFM_TESTOUT gesetzt und Datei vorhanden)
  Importiert direkt aus lib/export_csv.py (build_lookup, process_blocks,
  build_bogen_merkmale, build_weiche_merkmale, load_json).

tests/test_omniflo.lsp (173 Zeilen):
  AutoLISP-Tests fuer omni:insert-bogen und omni:insert-weiche.
  Prueft Block-Einfuegung, Attribut-Setzung (HOEHE, DREHUNG, ARTINR)
  und Fehlerverhalten bei ungueltigen Parametern. Laeuft direkt in
  BricsCAD via (load "tests/test_omniflo.lsp").

tests/testdata/omniflo_tests.json (114 Zeilen):
  Testdaten fuer test_omniflo.py: Definiert Testfaelle fuer Boegen
  (je Winkel: 22.5, 45, 67.5, 90, 180) und Weichen (90°, 45°, koerper,
  parallel) mit erwarteten Merkmale-Feldern und Beispiel-SivasNr.

tests/conftest.py:
  Pytest-Fixtures fuer den Testlauf: data_dir, testdata_dir,
  output_dir und omniflo_lookup (laedt Katalog-JSON falls vorhanden,
  sonst leeres Dict als Fallback).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-12 11:27:08 +02:00
m.stangl 3aed8fe176 debug beim Varioförderer dazu. dbgreturn routine gibt den Wert zurück. neues Test Konzept für unsere lisp Funktionen implementiert 2026-05-28 17:34:02 +02:00