Closed sidey79 closed 1 year ago
Merging #1135 (2d9a139) into master (946f0df) will increase coverage by
1.20%
. The diff coverage is83.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%) |
:arrow_down: |
modules | 66.83% <83.83%> (+1.20%) |
:arrow_up: |
perl | 90.46% <ø> (+0.12%) |
:arrow_up: |
unittests | 66.83% <83.83%> (+1.20%) |
:arrow_up: |
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%) |
:arrow_down: |
lib/Test2/SIGNALduino/RDmsg.pm | 74.74% <71.42%> (-4.57%) |
:arrow_down: |
t/FHEM/00_SIGNALduino/08_DeviceData_rmsg.t | 79.26% <75.00%> (-2.22%) |
:arrow_down: |
... and 33 more |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Bei mir steht, Du hättest 24 commits hochgeladen. Sieht so aus wie diese, welche ich zusammengefasst hatte. Kann das sein?
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.
@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.
@sidey79 ja mach das. Ich werde dann schauen wenn du ihn überschrieben hast.
@sidey79 ja mach das. Ich werde dann schauen wenn du ihn überschrieben hast.
erledigt :)
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?
@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.
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.
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.
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.
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.
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.
Hier nennt sich der der Hauptbranch "master". Neuerdings wird hier "main" verwendet aber es kann auch jeder andere Branchname zum Hauptbranch erstellt werden.
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.
Das war nach meinem Verständnis der Plan: Siehe https://github.com/RFD-FHEM/SIGNALduino_TOOL/issues/87#issuecomment-1345399861
Wie sieht denn eine Datei für Tests aus?
Ich fasse mal zusammen was ich verstanden habe:
SD_Device_ProtocolList.json
wird nicht mehr direkt durch die Tests aufgerufen. Es ist eine Datei die von / für das TOOL ist.
Jedes Modul erhält eine (ggf. auch mehrere) eigene TestData.json
. TestData.json
und Modulversion sind je Branch aufeinander abgestimmt (kompatibel).
Die RMSG Tests für das 00_SIGNALduino Modul basieren ebenfalls auf den TestData.json
. Sofern das Modul im gleichen REPO liegt ist das einfach. Wenn das Modul ausgelagert ist z.B. RSL muss ich mir noch was überlegen. Vielleicht kann ich das in die Metadaten vom Modul hinterlegen wo die Datei zu finden ist.
Ich nehme an, Du hattest etwas anderes verstanden ;)
Ich hatte das mittels Script extrahiert. Das Sortiert aber etwas anders als Du es gemacht hast. Vermutlich fehlen da noch mehr Daten.
Den Fehler habe ich gefunden. Es wurde immer nur der 1. Datensatz extrahiert. Ich hole jetzt mal die anderen nach.
Hier nennt sich der der Hauptbranch "master". Neuerdings wird hier "main" verwendet aber es kann auch jeder andere Branchname zum Hauptbranch erstellt werden.
Das habe ich richtig verstanden und denke das ist klar für alle.
Das war nach meinem Verständnis der Plan: Siehe RFD-FHEM/SIGNALduino_TOOL#87 (comment)
Wie sieht denn eine Datei für Tests aus?
Eine Vorlage sehe so aus am Beispiel SD_AS
[
{
"data" : [
{
"comment" : "self build arduino sensor with voltage output",
"dmsg" : "P2#0880370E",
"internals" : {
"DEF" : "voltage_0",
"NAME" : "ArduinoSensor_voltage_0"
},
"minProtocolVersion" : "1.29",
"readings" : {
"battery" : "2",
"batteryState" : "ok",
"batteryVoltage" : "3639",
"state" : "V: 3.64",
"trigger" : "auto",
"voltage" : "3.64"
},
"revision_entry" : "2021-05-26 23:11:19",
"revision_modul" : "14_SD_AS.pm 350 2020-10-01 20:16:11Z elektron-bbs",
"rmsg" : "MS;P0=-503;P1=460;P3=-1024;P6=-9946;D=16101010101310101013101010101010101010131310131313101010101313131015;CP=1;SP=6;O;m2;",
"user" : "elektron-bbs"
},
{
"comment" : "self build arduino sensor with temp output",
"dmsg" : "P2#0680E580",
"internals" : {
"DEF" : "temp_0",
"NAME" : "ArduinoSensor_temp_0"
},
"minProtocolVersion" : "1.29",
"readings" : {
"battery" : "ok",
"batteryState" : "ok",
"state" : "T: 22.9",
"temperature" : "22.9",
"trigger" : "auto"
},
"revision_entry" : "2021-05-26 23:00:22",
"revision_modul" : "14_SD_AS.pm 350 2020-10-01 20:16:11Z elektron-bbs",
"rmsg" : "MS;P1=484;P2=-474;P4=-990;P6=-9960;D=16121212121214141214121212121212121414141212141214141212121212121215;CP=1;SP=6;O;m2;",
"user" : "elektron-bbs"
},
{
"comment" : "self build arduino sensor with raw output",
"dmsg" : "P2#0AC30E01",
"internals" : {
"DEF" : "raw_3",
"NAME" : "ArduinoSensor_raw_3"
},
"minProtocolVersion" : "1.29",
"readings" : {
"battery" : "3",
"batteryState" : "ok",
"raw" : "270",
"state" : "S: 270",
"trigger" : "auto"
},
"revision_entry" : "2021-05-26 23:01:27",
"revision_modul" : "14_SD_AS.pm 350 2020-10-01 20:16:11Z elektron-bbs",
"rmsg" : "MS;P2=-9999;P3=504;P4=-511;P5=-965;D=32323434343435343534353534343434353534343434353535343434343434343435;CP=3;SP=2;m2;",
"user" : "elektron-bbs"
},
{
"comment" : "self build arduino sensor with humidity output",
"dmsg" : "P2#09803A82",
"internals" : {
"DEF" : "humidity_0",
"NAME" : "ArduinoSensor_humidity_0"
},
"minProtocolVersion" : "1.29",
"readings" : {
"battery" : "ok",
"batteryState" : "ok",
"humidity" : "57",
"state" : "H: 57",
"trigger" : "auto"
},
"revision_entry" : "2021-05-26 23:03:54",
"revision_modul" : "14_SD_AS.pm 350 2020-10-01 20:16:11Z elektron-bbs",
"rmsg" : "MS;P0=-9561;P1=458;P2=-527;P4=-982;D=10121212121412121414121212121212121212141414121412141212121212141215;CP=1;SP=0;m2;",
"user" : "elektron-bbs"
}
],
"id" : "2",
"module" : "SD_AS",
"name" : "ArduinoSensor"
}
]
Ich nehme an, Du hattest etwas anderes verstanden ;)
Ja zum Teil.
Ich überlege, wie wir auf einen Nenner finden ohne uns im Kreise zu drehen.
Jedes Modul erhält eine (ggf. auch mehrere) eigene TestData.json. TestData.json und Modulversion sind je Branch aufeinander abgestimmt (kompatibel).
Erkenntnis für mich ist soeben die Aussage, das im Masterbranch (Hauptbranch) nicht mehr das komplette JSON durchlaufen wird für tests. Da der RMSG Tests auf Basis vom Modulname und den hinterlegten Daten aus der testData.json verarbeitet wird.
Meine ersten Gedanken:
Das zerstört den Gedanke von damals, das sämtliche Devices, welche mit dem SIGNALduino verarbeitet werden, gesammelt werden in dem JSON vom TOOL. Es gäbe 2 Varianten
Ungern möchte uns im Kreise drehen lassen, da es genügend andere offenen Baustellen gibt.
PS: Gern belasse es so wie dein jetziger Ansatz ist und wir führen es "doppelt" und du solltest du mit dem Ergebnis der Tests unzufrieden sein, musst du Daten ergänzen. PS2: vorerst G8 erstmal :-)
Hmm, ich Stelle mir das so vor, dass das TOOL die Daten einfach aus einer anderen Quelle lädt und wir diese über die Metadaten bekannt machen.
Dadurch wäre doch alles vereinfacht.
Hmm, ich Stelle mir das so vor, dass das TOOL die Daten einfach aus einer anderen Quelle lädt und wir diese über die Metadaten bekannt machen.
Dadurch wäre doch alles vereinfacht.
Alle Daten im TOOL werden manuell eingepflegt beim entwickeln. Diese kannst du nicht irgendwo auslesen. ;)
Alle Daten im TOOL werden manuell eingepflegt beim entwickeln. Diese kannst du nicht irgendwo auslesen. ;)
Hmm, das ist eine Frage von an welcher Stelle werden sie eingepflegt. Vielleicht macht es keinen Unterschied, ob sie in dem einen oder anderen Repo hinterlegt werden. Hauptsache ist doch, dass alle Tools an die Daten kommen.
Hmm, das ist eine Frage von an welcher Stelle werden sie eingepflegt. Vielleicht macht es keinen Unterschied, ob sie in dem einen oder anderen Repo hinterlegt werden. Hauptsache ist doch, dass alle Tools an die Daten kommen.
Als erstes werden die Daten bisher immer im JSON eingepflegt, da es dort einen einfachen "Push via BUTTON" gibt. Wenn du auf die Erweiterung der Tests dann bestehst bzw. um den Code abzusichern, dann würde es mit Copy und Paste zu dir in die testData kommen.
Von welchem Repro diese kommen oder abgerufen werden, ist sicherlich egal.
Ich tendiere gerade dazu, es so wie jetzt beizubehalten und wir führen die Daten so doppelt bzw. erst beim Wunsch von Daten im Test werden wir diese wie oben genannt via C&P in die Files eintragen. Unabhängig habe ich vielleicht eine Idee, meine "Push via BUTTON Methode" ggf. zu überarbeiten, das ich mir die dazugehörige Testdatei herunter lade und erweitere.
PS: Wieso schlagen die Tests hier ab und zu fehl? Diese waren doch schonmal "grün" ?
PS2: Nur eine spontane Idee, ist es ein großer Aufwand die Testfiles von dir automatisch zu füllen mit einem Script welche die Daten aus dem JSON holt? ... ODER ist es einfacher wenn man dies via Schleife durchläuft und ggf. "Extra Spezialfälle" in eine weitere Datei testData sepaarat schreibt? <--- nur ein Gedankenspiel
Ich tendiere gerade dazu, es so wie jetzt beizubehalten und wir führen die Daten so doppelt bzw. erst beim Wunsch von Daten im Test werden wir diese wie oben genannt via C&P in die Files eintragen. Unabhängig habe ich vielleicht eine Idee, meine "Push via BUTTON Methode" ggf. zu überarbeiten, das ich mir die dazugehörige Testdatei herunter lade und erweitere.
So in der Art hatte ich das gemeint. Die doppelte Pflege braucht es dann aber vermutlich nicht mehr.
PS: Wieso schlagen die Tests hier ab und zu fehl? Diese waren doch schonmal "grün" ?
Weil jetzt ordentlich getestet wird und nicht bei Abweichungen der Fehler unterdrückt wird ;)
Die letzte offen Abweichung war noch eine "alte" Schuld. Die Werte für dispatch_repeats
haben bei einigen Einträgen nicht gestimmt. Ich habe das angepasst, sollten jetzt fehlerfrei durchlaufen. *bingespannt*
PS2: Nur eine spontane Idee, ist es ein großer Aufwand die Testfiles von dir automatisch zu füllen mit einem Script welche die Daten aus dem JSON holt? ... ODER ist es einfacher wenn man dies via Schleife durchläuft und ggf. "Extra Spezialfälle" in eine weitere Datei testData sepaarat schreibt? <--- nur ein Gedankenspiel
Das Schema ist in beiden Fällen identisch, daher ist es kein Problem es zu schreiben.
So habe ich die Daten letztlich auch rüber geholt:
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 :)
So habe ich die Daten überführt:
#!/bin/perl
use Data::Dumper;
use JSON;
my $testDataArray=undef;
sub loadJson {
my $url = shift;
my $json_text;
if ($url =~ /^https:\/\//i)
{
use HTTP::Tiny;
my $response = HTTP::Tiny->new->get($url);
die("Failed!\n") unless $response->{success};
$json_text = $response->{content};
} else {
$json_text = do {
open(my $json_fh, "<:encoding(UTF-8)", $url)
or die(qq[Can't open $url: $!\n]);
local $/;
<$json_fh>
};
}
$testDataArray = eval { decode_json($json_text) };
if($@){
die("open json file SD_Device_ProtocolList was not possible $?");
}
}
sub filterTestDataArray {
my $modulename = shift;
$modulename =~ s/^[0-9][0-9]_//; # Remove leading digtis
my @results;
return if (ref $testDataArray ne 'ARRAY');
while ( (my $pID, my $testSet) = each (@{$testDataArray}) )
{
if (defined $testSet->{module} && $testSet->{module} eq $modulename)
{
push @results, $testSet
}
}
return @results;
}
loadJson('https://raw.githubusercontent.com/RFD-FHEM/SIGNALduino_TOOL/master/FHEM/lib/SD_Device_ProtocolList.json');
my $json = JSON->new;
$json = $json->pretty([$enable]);
my @tData = filterTestDataArray($ARGV[0]);
use Data::Dumper;
#exit 0;
for my $p (0 .. $#tData )
{
for my $i (0 .. scalar @{$tData[$p]{data}}-1 )
{
if ( !exists $tData[$p]{data}[$i]{tests} ) {
$tData[$p]{data}[$i]{tests}[0] = ({ "comment" => "#$i"});
}
for my $element (qw /attributes setreading returns/)
{
if ( exists $tData[$p]{data}[$i]{$element} ) {
$tData[$p]{data}[$i]{tests}[0]{$element} = $tData[$p]{data}[$i]{$element};
delete ($tData[$p]{data}[$i]{$element});
}
}
}
}
#my @result = @tData ;
my $json_text = $json->utf8->encode( \@tData );
#print $ARGV[0];
#print "\n";
print $json_text;
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.
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/
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.
@HomeAutoUser
Ich würde es bei diesem Stand zunächst einmal belassen wollen.
@HomeAutoUser
Ich würde es bei diesem Stand zunächst einmal belassen wollen.
Geht in Ordnung.
Mich würde interessieren, wann und wohin dann welche Testdaten sollen.
@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.
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?
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.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
[ ] Bugfix (please link issue)
[ ] Feature enhancement
[ ] Documentation update
[x] 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.
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.
hopefully not