Update json testdata to new schema

[sidey79]

• Please check if the PR fulfills these requirements

• Tests for the changes have been added / modified (needed for for bug fixes / features)
• commandref has been added / updated (needed for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Bugfix (please link issue)
• Feature enhancement
• Documentation update
• Unittest enhancement
• other

• What is the current behavior?
  (You can also link to an open issue here, if this describes the current behavior)

Test data is taken from another repository.
Since schema update in the other repository, the tests are not running as expected.

• What is the new behavior (if this is a feature change)?

Test data is taken from this repository if testdata is available.
If there is no testdata avaailable, testdata is loaded from url if specified and module is installed.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

hopefully not

• Other information:

[codecov]

Codecov Report

Merging #1135 (2d9a139) into master (946f0df) will increase coverage by 1.20%.
The diff coverage is 83.83%.

@@            Coverage Diff             @@
##           master    #1135      +/-   ##
==========================================
+ Coverage   65.63%   66.83%   +1.20%     
==========================================
  Files         138      135       -3     
  Lines        9882     9824      -58     
  Branches     1572     1570       -2     
==========================================
+ Hits         6486     6566      +80     
+ Misses       2137     1966     -171     
- Partials     1259     1292      +33     

Flag	Coverage Δ
fhem	56.31% <83.83%> (-1.60%)	⬇️
modules	66.83% <83.83%> (+1.20%)	⬆️
perl	90.46% <ø> (+0.12%)	⬆️
unittests	66.83% <83.83%> (+1.20%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
t/FHEM/10_FS10/09_ParseData.t	94.11% <ø> (ø)
t/FHEM/10_SD_GT/09_parseData.t	94.11% <0.00%> (ø)
t/FHEM/10_SD_Rojaflex/09_autocreate_devices.t	100.00% <ø> (ø)
t/FHEM/14_BresserTemeo/09_autocreate_devices.t	100.00% <ø> (ø)
t/FHEM/14_SD_UT/01_attr.t	100.00% <ø> (ø)
t/FHEM/14_SD_WS/09_autocreate_devices.t	100.00% <ø> (ø)
t/FHEM/14_SD_WS09/02_SD_WS09_WindDirAverage.t	100.00% <ø> (ø)
t/FHEM/10_SD_Rojaflex/09_parseData.t	94.11% <66.66%> (-4.30%)	⬇️
lib/Test2/SIGNALduino/RDmsg.pm	74.74% <71.42%> (-4.57%)	⬇️
t/FHEM/00_SIGNALduino/08_DeviceData_rmsg.t	79.26% <75.00%> (-2.22%)	⬇️
... and 33 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[sidey79]

Bei mir steht, Du hättest 24 commits hochgeladen.
Sieht so aus wie diese, welche ich zusammengefasst hatte.
Kann das sein?

[HomeAutoUser]

Ich habe eigentlich nur deinen aktuellen Stand in GitHub desktop holen wollen und da kam die Frage… wunderte mich auch schon und verglich da alles. Es sind alle deine letzten Stände. Ich weiß nicht wieso da „MergeBranch…“ kam. Wollte dir ggf helfen und die Dateien auf ein Schema zu bringen + zusätzlich hide von mir erstellen testData Files zur Verfügung stellen.

[sidey79]

@HomeAutoUser

Wenn Du nichts verändert hast, dann würde ich den Branch überschreiben und die 24 commits löschen.
Mit github desktop arbeite ich nicht, aber vermutlich ist es einfacher wenn Du ihn lokal löschst und neu abholst, da ich die Historie zwischendurch aufgeräumt habe.

[HomeAutoUser]

@sidey79 ja mach das.
Ich werde dann schauen wenn du ihn überschrieben hast.

[sidey79]

@sidey79 ja mach das. Ich werde dann schauen wenn du ihn überschrieben hast.

erledigt :)

[sidey79]

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen.
So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

[sidey79]

@HomeAutoUser

Die Tests sind ja nun zumindest mal durchgelaufen.
Offenbar, sind aber nicht alle mir rüber gekommen, was mich wundert. Z.B. fehlt der Datensatz zu "SD_WS_50_SM".

Ich hatte das mittels Script extrahiert. Das Sortiert aber etwas anders als Du es gemacht hast.
Vermutlich fehlen da noch mehr Daten.

[HomeAutoUser]

Offenbar, sind aber nicht alle mir rüber gekommen, was mich wundert. Z.B. fehlt der Datensatz zu "SD_WS_50_SM".

Was möchtest du davon haben?
Im durchlaufenden JSON ... wenn du das noch machst, sind dsmg hinterlegt wo der dispatched getestet wird.

Wenn du nun den Datensatz 1:1 kopierst in deine "testData", so testen wir doppelt.
Es muss ein Test mit der Bezeichnung " ... Opus_XT300 ..." geben.

Vermutlich fehlen da noch mehr Daten.

Was soll fehlen bzw. was denkst du, was fehlt?

Info:
Deine Tests, durchlaufen das komplette JSON einmal durch, wo mehrere dmsg´s drin sind als bei deinen Tests. Wir testen so den normalen Dispatch mit den Readings. Alles andere wären Sondertests. Bitte nicht doppelt testen.

[sidey79]

Ich wüsste jetzt nicht was doppelt getestet wird.
Aktuell wird hier weniger als im Haupt Branch getestet und der eine Datensatz war ein Beispiel.

Soll das Tool denn die testData.json schreiben können oder nicht? Wenn ich meinen Export überarbeite, gehen deine Anpassung halt wieder weg, daher wollte ich das jetzt nicht machen.

[elektron-bbs]

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen. So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

Das sehe ich auch so.
Ich habe den Code in 14_SD_WS.pm und 14_BresserTemeo mal verglichen - sieht sich verdammt ähnlich. Das war wohl eines der ersten Protokolle, die ihr in die 14_SD_WS.pm überführt habt.

[HomeAutoUser]

Ich wüsste jetzt nicht was doppelt getestet wird.
Aktuell wird hier weniger als im Haupt Branch getestet und der eine Datensatz war ein Beispiel.

Was ist für dich ein Hauptbranch und wie ist dein komplettes Konzept angedacht.

Soll das Tool denn die testData.json schreiben können oder nicht? Wenn ich meinen Export überarbeite, gehen deine
Anpassung halt wieder weg, daher wollte ich das jetzt nicht machen.

Von der Überlegung war ich abgekommen weil da zu viele Faktoren einspielen zum Vergleichen. Derzeit lasse ich auf Basis des TOOL´s und dessen SD_Device_ProtocolList.json Dateien für Tests generieren um dir Vorlagen zu bieten. Das man das besser vergleichen kann, hatte ich das Schema in den testData´s gleich gemacht.

Bleibt der Zustand https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/lib/Test2/SIGNALduino/RDmsg.pm#L17:L26 so? Leider kenne ich nicht den kompletten Umsetzungsgedanke nicht vollständig.

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen. So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

Dito.

[HomeAutoUser]

Ich bin aber immer noch überzeugt, dass SD_Device_ProtocolList.json nicht nötig ist, wenn direkt mit den testData.json gearbeitet werden könnte :)

Das mag sein, WENN man nur die Daten deiner Module mit dem TOOL verarbeiten würde. Da aber auch darin Daten von Fremdmodulen sind, welche du nicht testest, so negiere ich deine Aussage :-P

Ich war mal so frei und habe eine leichte Warning gefixt grins. So minimiert man die Ausgaben im gesamt RAW Log hihi.

[sidey79]

Ich bin aber immer noch überzeugt, dass SD_Device_ProtocolList.json nicht nötig ist, wenn direkt mit den testData.json gearbeitet werden könnte :)

Das mag sein, WENN man nur die Daten deiner Module mit dem TOOL verarbeiten würde. Da aber auch darin Daten von Fremdmodulen sind, welche du nicht testest, so negiere ich deine Aussage :-P

Ja da ist was dran. An die "anderen" Module habe ich nur kurz gedacht, aber auch da könne das Tool in einen Ordner t/FHEM//testData.json schreiben, nur das auffinden kann dann nicht über die Metadaten erfolgen, das geht dann nur über eine Suche im Dateisystem. (Für beides ist der code hinterlegt)

Ich war mal so frei und habe eine leichte Warning gefixt grins. So minimiert man die Ausgaben im gesamt RAW Log hihi.

Da gibt es noch einige aber jetzt wollte ich erst mal diesen Teil fertig abschließen.

[sidey79]

@HomeAutoUser

Ich würde es bei diesem Stand zunächst einmal belassen wollen.

[HomeAutoUser]

@HomeAutoUser

Ich würde es bei diesem Stand zunächst einmal belassen wollen.

Geht in Ordnung.

[elektron-bbs]

Mich würde interessieren, wann und wohin dann welche Testdaten sollen.

1. Sehe ich das richtig, das für die Test bei Github die Daten aus dem SIGNALduino-Tool nicht mehr verwendet werden?
2. Wenn Testdaten bei den Modulen sind, werden mir Fehler dann schon bei Änderungen im neuen Branch angezeigt oder auch wieder erst beim Pull-Request?

[sidey79]

@elektron-bbs

Daten aus dem Signalduino Tool werden aktuell keine mehr direkt verwendet.

Verwendet wird vorzugsweise was lokal im Repository liegt.
Wenn es dort keine gibt, werden auch welche verwendet, welche in den Meta Daten verlinkt wurden. Das trifft aber auf die hier im Repo hinterlegten nicht zu, da diese lokal hinterlegt wurden.

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt.
Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

[elektron-bbs]

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt. Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

Man wird aber hoffentlich darauf hingewiesen, das Fehler aufgetreten sind?

[sidey79]

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt. Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

Man wird aber hoffentlich darauf hingewiesen, das Fehler aufgetreten sind?

Ja der Fehlerbericht kommt per E-Mail.
War aber auch vor diesem PR schon so.