Closed JHCD closed 9 years ago
Hab deinen Beitrag mal bearbeitet - man kann jetzt alles was fertig ist einfach abhaken ;-)
EDIT: Man könnte die Testdaten in verschiedenen Dateien ablegen. FMS - ZVEI - POC512 ..... Und dann für den Testbetrieb jeweils nur diese nutzen, welche auch über den "-a" Demodulations Parameter angegeben wurden.
Für die Entwicklung sollte das in meinen Augen egal sein, wir bauen Plugins für alle Services. Außerdem soll das dazu führen, wenn ich z.B. für mein POC etwas zentral änder, Dein ZVEI noch geht. Quasi ein Regressionstest.
Wenn der Test-Treiber dann soweit ist, wird doch die plugin_test.py völlig überflüssig oder? Die macht ja nicht mehr, als:
Da plugin_test.py hat sowieso keiner gepflegt -> raus
FALSCH: Freilich habe ich das gepflegt :smile: Läuft auch hervorragend... Aber ja ich seh's ja ein, mit dem Test-Treiber überflüssig :laughing:
Hatte grade wieder eine meiner hellen Sekunden.... Bei 36° ....
Was haltet ihr davon wenn man ein Script erstellt welches dann per Auswahl die verschiedenen Meldungen an die Routine übergibt? Fände ich schon relativ cool zum testen, statt im Quellcode rumzustochern ?
Das ist der Job des Testdaten-Treibers, alle Testdaten durchlaufen zu lassen.
@kevinkleist
Es soll am Ende dann so aussehen, dass man boswatch mit dem Parameter -t
startet und dann einfach Testdaten für alle möglichen relevanten Fälle - siehe oben - gesendet werden. So kann man Script, Funktionen und die Plugins auf alle wichtigen Fälle testen.
multimon und rtl_fm werden in diesem Testmode dann erst gar nicht geladen
Wäre es nicht ganz nett für die Entwicklung die einzelnen Fälle auswählen zu können ?
Am 01.07.2015 um 19:04 schrieb Schrolli91 notifications@github.com:
@kevinkleist Es soll am Ende dann so aussehen, dass man boswatch mit dem Parameter -t startet und dann einfach Testdaten für alle möglichen relevanten Fälle - siehe oben - gesendet werden. So kann man Script, Funktionen und die Plugins auf alle wichtigen Fälle testen.
— Reply to this email directly or view it on GitHub.
Das mag für eine Fragestellungen so aussehen, wenn man dadurch etwas anderes kaputt macht, dauert die Fehlersuche lange und es müssen im Zweifel teile doppelt entwickelt werden...
Es wird eine Testdaten-Datei genutzt werden, die Du lokal aufräumen/ändern kannst (meine wird z.B. zusätzlich unsere Echtdaten enthalten)
Vor einem Commit / Merge Request ist ein Gesamttest verpflichtend. Außerdem reden wir hier von Laufzeiten kleiner einer Minute.
Richtig - @JHCD hat schon Recht - was bringt es nur POCSAG zu testen, evtl habe ich bei meinen Änderungen etwas verändert nachdem ZVEI nicht mehr korrekt arbeitet - und um sowas sicher auszuschließen müssen immer alle Tests durchlaufen werden. Nur so kann man sich ~99% sicher sein, dass die Software in jedem Fall korrekt arbeitet.
Habe mal POCSAG erweitert - Ich weis nur nicht genau wie ein Datensatz ohne Text aussieht? Wer Testdaten beisteuern mag - gerne anonymisiert/verändert her damit :smiley:
Testdatentreiber wurde implementiert.
Beim Aufruf mit -t werden alle Daten aus testdata/testdata.txt
ausgeführt
Da das Testdaten Modul an sich ja nun arbeitet würde ich das Issue schließen. Wenn Fehler auftreten einen Bug melden...
Für den Test der umfangreichen Funktionen wird ein Testtreiber mit entsprechenden Testdaten benötigt.
1.) [x] Implementierung des Testreibers (Aufruf mit -t) 2.) Bereitstellung von Testdaten-Strings, die möglichst viele Funktionen abdecken: