-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UnitTest - Anregungen | weitere Verfahrensweise | Fragen | Klärungen ... #676
Comments
Meine Sicht ist, dass in dem Prüfdaten (JSON Datei) die Anzahl an Dispatches hinterlegt sein müsste. |
Ja bei manchen ist der Eintrag repeats vorhanden.
Interprätiere ich das so, das du den Test so formuliert hast, das man es nicht prüfen kann? Testen im Code kannst du nur derzeit, indem du das Attribut
dispatcht wurde. Der dort dispatchte Wert - 1 sind die repeats. |
Wenn ich es richtig in Erinnerung habe, dann gibt der Wert Repeats heute an, wie viele Wiederholungen einer Nachricht im Signal enthalten sind. Das SIGNALDuino Modul kennt aber in diesem Sinne keine "Wiederholungen". Diese werden nirgendwo ausgegeben noch berücksichtigt. Es werden allerdings Dispatches für jede erkannte Nachricht abgesetzt. Das ist vermutlich oft mit der Anzahl der Wiederholungen identisch, allerdings nicht in allen Fällen. Daher, repeats im Sinne von wie viele sind im Signal ist für einen Test eher unwichtig. |
Mit diesem Wissen würde ich ja vorschlagen, wir ändern den Text im Test, das es nicht zu weiteren Stolperstellen kommen kann. Zusätzlich würde ich vorschlagen, den bisherigen Test so zu modifizieren, das 1.) Prüfung auf repeats Eintrag JA / nein |
Wieso nicht repeats durch dispatches im json ändern? |
Ja es ginge ... augenroll da muss ich den Code anpassen. Da machst du aber den Test so wie wir wollen :-D Kommen wir aber nicht in Kollisionen mit der Attributbezeichnung ? Wir beeinflussen das mit der Definierung im Wäre nicht |
Ich dachte es wäre nur ein suchen / ersetzen, aber Du steckst da tiefer drin wo alles angepasst werden müsste. maxMuMsgRepeat haben wir damals so benannt, weil wir dachten es wären die Anzahl an Wiederholungen. |
ich schaue es mir mal an und auf die Schnelle denke ich, das die Ersetzung von
Ich habe im Kopf eine Anpassung welche wir dann einfach Einpflegen und als "Kompatiblitätsschleife" drin lassen. Somit können wir
Ich muss nur aufpassen in welchen Schritten wir das Vorhaben angehen. Verständnissfrage: |
Klingt nach einem Plan :) Es ist somit sinnvoll, den Test und die Änderung des Attributes in einem PR zu erledigen. |
Ich habe schonmal begonnen es abzuändern und werde morgen bestimmt das ganze Überführen. Dia Attributsumbenennung im SIGNALduino habe ich noch nicht angetastet weil diese ist ja vom TOOL erstmal unabhängig und das wäre dann der nächste Punkt. |
Hallo, ich habe mir das nochmal überlegt bzw angesehen mit dem Attributnamen im Signalduino. Für uns kommen nur 3 Fälle in Betracht.
Also nehmen wir erstmal nur die JSON Änderung in Betracht mit den nötigen Tests welche angepasst werden mussten. |
@sidey79 kann es sein, das der Test
|
Das ist mir neu, dass dieser Test abbricht. Die doppelten ; sind aber seltsam in Check. Würde ich nicht erwarten. Wo bricht der Test denn ab? Die letzten PRs waren doch sauber |
Detailausgabe siehe Post #676 (comment) Ich hatte mal einen Commit selbst bei mir ausgeführt weil ich etwas änderte. Da fiel mir das auf. Abbruch:
Werte welche genutzt und abgefragt werden:
|
@sidey79 ich möchte nochmal auf den Test von dir hinweisen. Ich habe soeben die aktuelle dev Version mit dem Test test_sub_SIGNALduino_Set-definition.txt laufen lassen und da treten die o.g. Fehler auf. Ich möchte ungern verhindern, das dieser Test erst später in der dev-r35 uns dann ins stolpern bringt ;-) |
Mit welcher fhem.cfg startest Du Fhem bevor der Test läuft? |
@sidey79, die lokale fhem.cfg ist glaube nicht der Grund. Auch hier Es ist ein PR welcher dann deine kompletten Tests abläuft und somit die fhem.cfg nutzt online. |
Hmm, hast Du eine Idee wieso es in #813 dann gestern durchgelaufen ist? |
@sidey79 Bei deinem Test gestern lief der Test 39 (unten aufgelistet problemlos durch). Bei dem PR wurde die Setliste erweitert und du scheinst fest auf Werte zu prüfen.
Alles andere verlief mit dem selben Ergebnis durch. Der Test müsste dort ggf. optimiert werden oder vielleicht als "flexibel" gestaltet werden.
Hier fehlt nun der Test auf
ODER den Wert fest verankern, dann ginge es natürlich auch. EDIT: |
RFFHEM/UnitTest/tests/test_DeviceData_rmsg-definition.txt
Line 69 in ac06a72
Wie geht es hier weiter?
Was wertest du aus oder möchtest du auswerten?
The text was updated successfully, but these errors were encountered: