FHEM Forum

FHEM - Entwicklung => FHEM Development => Perl Ecke => Thema gestartet von: herrmannj am 10 Mai 2020, 12:54:23

Titel: Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 12:54:23
Wie würde man denn entsprechende Unit Tests organisieren können? Hat da jemand Ideen und Erfahrungen?
Titel: Antw:Unit Test?
Beitrag von: Sidey am 10 Mai 2020, 14:36:25
Ja, kommt aber drauf an, was Du testen möchtest.

Möchtest Du Fhem Module oder Perl Module testen?

Für Tests von Fhem Modulen habe ich folgendes Modul entwickelt:

https://github.com/fhem/UnitTest

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 16:14:04
Zitat
Möchtest Du Fhem Module oder Perl Module testen?
Ist das denn ein Widerspruch? Wie organisiert man denn sowas? Das benötigt doch auch eine Infrastruktur? Im cpan liegen die doch immer unter t (?)
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 10 Mai 2020, 17:11:42
Ist das denn ein Widerspruch? Wie organisiert man denn sowas? Das benötigt doch auch eine Infrastruktur? Im cpan liegen die doch immer unter t (?)

Widerspruch wohl nicht gerade, aber "FHEM Module" sind erstmal wenig auf Testing ausgerichtet.

Kannst ja mal bei HoBo reinschielen wie dort die Unit-Tests laufen, bzw. wie die beim Commit automatisch angestossen werden.
Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 17:27:20
Soll das heißen da gibt's keine best practice?
Titel: Antw:Unit Test?
Beitrag von: Sidey am 10 Mai 2020, 18:07:53
Ich würde sagen best practice ist, Perl Module zu schreiben.

Wenn Du so ein Perl Modul testen willst, dann schreibst Du ein kleines Perl Programm. Dem kannst Du die Endung .t geben aber dazu zwingt dich niemand.
Dort bindest Du eine Test Suite und dein Modul welches Du testen möchtest ein.
Stichwort use :)

Wenn Du so ein FHEM Modul einbindest, wird es erst mal Fehler hageln.

%defs ist nicht bekannt, %modules usw.
Log3 kennt er nicht.
Weil das alles in Fhem.pl steckt kannst Du es auch nicht einfach mal so eben mit use  Einbinden.

An diesem Punkt kann man entweder eine Mock Umgebung aufbauen und all diese FHEM Funktionen emulieren.
Mir erschien das endlos viel Arbeit bei der man nie fertig wird und habe deshalb das UnitTest Modul unter Fhem entwickelt. So sind zumindest die ganzen FHEM Funktionen vorhanden.

Das ist nicht das gelbe vom Ei, aber irgendwie das was mir einigermaßen sinnvoll erschien um meinen Code gegen Tests prüfen zu lassen.

Beat practice ist vermutlich keine Funktionen und Variablen aus dem Hauptprogramm in einem Modul direkt zu verwenden. :)

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 10 Mai 2020, 18:32:21
Soll das heißen da gibt's keine best practice?

Klar gibt es die, aber die will man ja "hier" nicht hören. Abgesehen davon habe ich die schon 2-3mal irgendwo doch recht detailiert ausklabüstert.

Und wenn das Deine Antwort auf meinen dezenten Verweis auf's Hobo Repository ist, dann sage ich einfach, HoBo geht den best practice Weg.
Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 19:26:57
Ich höre immer wieder das man als pro Tests unbedingt braucht. Wenn Ich mir die Antworten so anschaue bin ich mir nicht mehr so sicher.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 10 Mai 2020, 20:59:17
 ::)

Ich fasse mal zusammen:

a) Wie würde man denn entsprechende Unit Tests organisieren können? Hat da jemand Ideen und Erfahrungen?
...
b) Ist das denn ein Widerspruch? Wie organisiert man denn sowas? Das benötigt doch auch eine Infrastruktur? Im cpan liegen die doch immer unter t (?)

c) Soll das heißen da gibt's keine best practice?

d) Ich höre immer wieder das man als pro Tests unbedingt braucht. Wenn Ich mir die Antworten so anschaue bin ich mir nicht mehr so sicher.

ad a) Ja, ich, siehe Bild. Sidey hat geantwortet (und zwar richtig): Perl Modul != FHEM Modul
Das was sich in FHEM Modul nennt ist meistens ein verkapptes .pl File, manchmal, selten und bestenfalls ein nicht-standardkonformes Perl Modul

ad b) Also kein Widerspruch, nur hat das Eine mit dem Anderen recht wenig zu tun,

ad c) Testing Best practice ist in PBP Kapitel 18 S. 420-427 abgehandelt, bzw. in dem Buch "Perl Testing" von Langworth&chromatic
Oder im CPAN, oder im HoBo Repo, wenn man projektnahe Beispiele will

Guggst Du da: https://gl.petatech.eu/root/HomeBot/-/tree/master/t/HoBo
Und da: https://gl.petatech.eu/root/HomeBot/-/blob/master/Makefile  (make test)
Bonus: https://gl.petatech.eu/root/HomeBot/-/blob/master/.gitlab-ci.yml  (automatisierte CI Toolchain)
Und Endergebnis dann da: https://gl.petatech.eu/root/HomeBot/-/jobs/151

Aber gut, als semi-pro hätteste da beim Verweis auf's Hobo Repo auch alleine klicken können.

Vielleicht habe ich nur falsch verstanden und die Frage lautete "Es gibt keine Unit-Test best practices "für FHEM module"?"

Dann lautet die Antwort hierauf... nein, bzw. ist 98_UnitTest wohl der beste Notnagel derzeit.

d) Ich kann Dich beruhigen, die Unsicherheit liegt vollumfänglich kausal auf Deiner Seite begründet.

Vielleicht vor dem nächsten Einzeiler-Fragestatment zumindest ansatzweise deutlich machen man hat die Hinweise durchgelesen?
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 10 Mai 2020, 21:06:03
Perl CPAN Module verwenden ueblicherweise das Test::Harness Perl Modul mit t/*.t als Argument, woraufhin der Reihe nach alle .t Dateien als Perl Programme ausgefuehrt werden, siehe auch "make test" in einem CPAN Paket. Innerhalb der .t Dateien wird haeufig Test::More verwendet, der Funktionen wie ok, is, etc anbietet, um die Pruefungen lesbar gestalten zu koennen.


Das o.g. UnitTest ist ein FHEM Modul, bei dem man bei der Definition ("normales" FHEM define) eine zu evaluirende Perl Expression angibt. Das wird nach dem Initialisieren von FHEM ausgefuehrt (je nach Attribut direkt oder als BlockingCall), und das Ergebnis in Readings/gespeichert. Das war eine startk vereinfachte Darstellung.


Hobo geht den Weg der CPAN-Module (mit Test::More und prove statt Test::Harness), und muss bei "echten" Tests (die mehr als Syntax testen) alle verwendeten globalen Funktionen und Variablen mocken.


Ob man als "pro" Tests unbedingt braucht: Tests haben Vorteile und Nachteile, ob die Energie hier oder anderswo besser investiert ist, sollte jeder fuer sich entscheiden.
Ab einem bestimmten Code-Coverage (habe gerade Devel::Cover entdeckt :) ) steigt der Muell-Faktor, weil man bestimmte Sachen nur dann testen kann, wenn man den Code auf Testen optimiert. Bei so einer Optimierung kann der Code unleserlich werden, und ich habe auch gesehen, wie man dabei "real-life" Bugs einbaut.
Unbestrittener Vorteil aus Sicht der Anwender: der Entwickler ist gezwungen sich laenger mit seinem Code zu beschaeftigen.
Ob der Entwickler das mit sich machen laesst, ist was Anderes.

Wenn Maintainer das Beduerfnis haben, fuer ihre FHEM-Module Tests schreiben zu wollen, bin ich bereit dafuer ein Framework bereitzustellen, bitte melden.
Titel: Antw:Unit Test?
Beitrag von: Sidey am 10 Mai 2020, 21:27:38
Das o.g. UnitTest ist ein FHEM Modul, bei dem man bei der Definition ("normales" FHEM define) eine zu evaluirende Perl Expression angibt. Das wird nach dem Initialisieren von FHEM ausgefuehrt (je nach Attribut direkt oder als BlockingCall), und das Ergebnis in Readings/gespeichert. Das war eine startk vereinfachte Darstellung.

Darin wird auch Test::More bereitgestellt um den Code ebenso wie in den .t Dateien testen zu können. Zwecks einschleusen von code, gibt es auch ein shell script.
Wobei ich beim Testen auf Test2 gewechselt bin, aber Test::More noch dafür gebrauche die Rückgaben des Testcodes abzufangen. Da bin ich bei Test2 einfach noch nicht durchgestiegen wie ich die Daten abfange. ;)


Hobo geht den Weg der CPAN-Module (mit Test::More und prove statt Test::Harness), und muss bei "echten" Tests (die mehr als Syntax testen) alle verwendeten globalen Funktionen und Variablen mocken.

Ich hab mich mittlerweile ich dazu entschieden, alle Subroutinen die nicht zwingend FHEM Funktionen / Variablen verwenden in ein Perl Modul auszulagern. Da kann man das dann auch machen. Ist quasi ein Zwischending :)

Ob man als "pro" Tests unbedingt braucht: Tests haben Vorteile und Nachteile, ob die Energie hier oder anderswo besser investiert ist, sollte jeder fuer sich entscheiden.
Ab einem bestimmten Code-Coverage (habe gerade Devel::Cover entdeckt :) )

Ich verwende Devel::Cover um zu sehen ob ich schwarze Flecken im Test habe.
Gerade komplexe Bedingungen sind ja manchmal nicht so leicht  alle abzuarbeiten, da hilft es schon ganz gut. Ob man jetzt eine coverage von 100% haben muss, das sollte jeder für sich entscheiden.
Ansonsten habe ich so viele verschiedene Varianten an Daten die verarbeitet werden, das könnte ich nie überblicken, ob es durch eine Änderung auf einmal ein Problem gibt.
Da helfen mir diese Tests einfach um zu verifizieren, dass alles noch so wie vorher klappt oder halt auch nicht.

Wenn Maintainer das Beduerfnis haben, fuer ihre FHEM-Module Tests schreiben zu wollen, bin ich bereit dafuer ein Framework bereitzustellen, bitte melden.

Ich melde mich mal, hast Du dir da schon was vorgestellt?


Grüße Sidey
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 10 Mai 2020, 21:36:01
Ob man als "pro" Tests unbedingt braucht: Tests haben Vorteile und Nachteile, ob die Energie hier oder anderswo besser investiert ist, sollte jeder fuer sich entscheiden.

Ich vermute mal, das Thema kommt hier überhaupt nur deswegen zur Sprache, weil der FHEM e.V. ne "Zukunfts-Strategiesitzung" hatte - oder?

Ob das Thema also nun wie schon in vergangenen Jahren wieder mit solchen Floskeln "Tests haben Vorteile und Nachteile" abgebügelt wird, soll nicht mein Problem sein, aber ich denke in der heutigen Zeit sollte man ein wenig Weltbürgerpflicht tun und gegen Fake-News vorgehen:

Tests haben keine Nachteile. Noch nicht einmal "mehr Arbeit", weil sie auf lange Sicht eine shitload an Arbeit abnehmen.
Wenn "zu Beginn mehr Arbeit = auf Dauer mehr Qualität" ein Nachteil ist, dann Hände weg von Tests liebe Kinder.

Zitat
Ab einem bestimmten Code-Coverage (habe gerade Devel::Cover entdeckt :) ) steigt der Muell-Faktor, weil man bestimmte Sachen nur dann testen kann, wenn
man den Code auf Testen optimiert.

Ich habe Devel::Cover seit 2010 im Einsatz. Es ist bewundernswert, mit welchen Statements Du so kurz nach der Entdeckung operieren kannst.

"Der Muell-Faktor steigt..."
"Man optimiert den Code auf Testen..."
"Bei so einer Optimierung kann der Code unleserlich werden, und ich habe auch gesehen, wie man dabei "real-life" Bugs einbaut."

Tatsächlich zeigen einem Tests (und Coverage) häufig wie wenig modular man den Code geschrieben hat. Nach meiner Einschätzung sind die "original main-Namespace" FHEM Module nicht testbar. Und nein, man muss auch nicht auf 100% Coverage hinarbeiten. 80% ist besser als nix und häufig startet man mit 10%. Daher:

Zitat
Wenn Maintainer das Beduerfnis haben, fuer ihre FHEM-Module Tests schreiben zu wollen, bin ich bereit dafuer ein Framework bereitzustellen, bitte melden.

Das ist löblich und Du bist natürlich frei hinsichtlich Deiner Zeitgestaltung, aber ich würde empfehlen erstmal das Namespace Problem in FHEM
in den Griff zu bekommen, bevor man sich das nächste neue nonkonforme Rad für ein nonkonformes System aus dem Knie schnitzt.

Zitat
Unbestrittener Vorteil aus Sicht der Anwender: der Entwickler ist gezwungen sich laenger mit seinem Code zu beschaeftigen.
Ob der Entwickler das mit sich machen laesst, ist was Anderes.

Ja, das sehen wir dann. Ich bin da mittlerweile indifferent, aber euphorischer Darwin Fan.
Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 21:37:03
Zitat
Ich melde mich mal, hast Du dir da schon was vorgestellt?
Ich denke da müsste man mal einen thread aufmachen um herauszufinden wie man entsprechende Unit Tests organisieren könnte.

Ich schlage vor wir sammeln da Ideen und Erfahrungen. Ist manchmal zäh aber man muss halt dranbleiben :)

Zitat
Ich hab mich mittlerweile ich dazu entschieden, alle Subroutinen die nicht zwingend FHEM Funktionen / Variablen verwenden in ein Perl Modul auszulagern.
Das Problem der Abhängigkeiten muss ja auch in anderen Projekten genau so existieren und wird da ja eventuell auch gelöst. Ist ja auch wünschenswert genau diese Schnittstellen in Tests abdecken zu können. Im Zweifel bräuchte man also eine "dummy" Umgebung welche die fhem.pl Variablen mit sinnvollen und falschen Werten vorbelegt ?

Ziel müssen ja automatisierte Tests sein - eine manuelle Interaktion macht da wenig Sinn.


Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 21:41:48

 aber ich würde empfehlen erstmal das Namespace Problem in FHEM
in den Griff zu bekommen, bevor man sich das nächste neue nonkonforme Rad für ein nonkonformes System aus dem Knie schnitzt.
Frage: wie müssen Tests organisiert werden um in der bestehenden Hierarchie (Namespace) maximalen Output für den Ersteller zu generieren?
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 10 Mai 2020, 21:48:23
Frage: wie müssen Tests organisiert werden um in der bestehenden Hierarchie (Namespace) maximalen Output für den Ersteller zu generieren?

Antwort: Wenn alles in main bleibt: Vergiss es. Im Forum hier ist eine Anleitung (ich glaube sogar mehrmals) wie man sein Modul in einen eigenen Namespace bekommt.

Sidey spricht von "Zwischending", genauso macht es HoBo aber auch:

xx_Name.pm (FHEM "Modul") Skelett welches ein use auf ein echtes perl Modul macht (was in "lib" lebt)

Diese "echten Module" werden getestet. Die Skelette nicht. Bzw. noch nicht, bzw. sind im Idealfall so eine dünne Wrapper-Schicht, dass ein Test selbst für Eiferer unnötig ist.



kurze Anmerkung: Wir reden hier immer noch über Unit-Tests

Es gibt keine "echten" Tests wie von Rudolf erwähnt. Vielleicht meinte er Integrationstests, bzw. Funktionstests.
Die kommen im Idealfall auch - aber später.

Wer fliegen will bevor er laufen kann wird meist auf die Schnauze fliegen.
Titel: Antw:Unit Test?
Beitrag von: herrmannj am 10 Mai 2020, 21:57:47
Schade dass man in main nichts testen kann. Wäre es dann nicht möglich einen sourcefilter zu verwenden und 'package main' gegen 'package hobo' im "Testobjekt" auszutauschen ? Dann müsste das doch gehen, ist ja dann nicht mehr main? Oder?
Titel: Antw:Unit Test?
Beitrag von: Sidey am 10 Mai 2020, 22:15:20
Frage: wie müssen Tests organisiert werden um in der bestehenden Hierarchie (Namespace) maximalen Output für den Ersteller zu generieren?

Lass die Tests in FHEM laufen, bis eine bessere Lösung gefunden wurde und lagere aus, was nicht wirklich zu FHEM gehört.
Ich hatte auch mal die wahnwitzige idee ich könnte aus fhem.pl ein fhem.pm machen um es mittels use einzubinden. Das wäre aber zu viel Anpassungarbeit gewesen.

Ich lasse die "UnitTests" innerhalb von FHEM über ein makefile durchlaufen.
Output ist ganz okay finde ich:
https://travis-ci.com/github/RFD-FHEM/RFFHEM/jobs/331167290

Und die nativen Perl Modultests lasse ich separat laufen:
https://github.com/RFD-FHEM/RFFHEM/runs/660623007?check_suite_focus=true

Die Variante von HOBO ist natürlich netter, aber dazu müssten die ganzen tollen Funktionen aus fhem.pl in ein Modul das man mit use einbinden kann. :)

Grüße Sidey


Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 11 Mai 2020, 10:05:25
Schade dass man in main nichts testen kann. Wäre es dann nicht möglich einen sourcefilter zu verwenden und 'package main' gegen 'package hobo' im "Testobjekt" auszutauschen ? Dann müsste das doch gehen, ist ja dann nicht mehr main? Oder?

Ich weiß nicht ob "man kann". Ich kann's nicht.

Und ob das Ding jetzt "main" heisst oder "hobo", ist wurst. Geht beides nicht.
Es sollte so heißen wie der Dateipfad ist. Und nur so und nur 1 package pro Datei.

lib/FHEM/MordsSamsungAV.pm -> package FHEM::MordsSamsungAV;

dann unter t

t/FHEM/MordsSamsungAV/*.t

Deswegen gibt es auch nicht package hobo, sondern

lib/HoBo.pm
lib/HoBo/Command.pm
...


und die zugeh. Testfiles.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 13 Mai 2020, 12:46:05
Ich habe ein Test-Framework fuer FHEM Module erstellt und eingecheckt.

Kurz:
% prove t/*/*.t
t/00_MQTT2_SERVER/00_parseMsg.t .... ok   
t/00_MQTT2_SERVER/01_autocreate.t .. ok   
All tests successful.
Files=2, Tests=4,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.36 cusr  0.06 csys =  0.48 CPU)
Result: PASS

Lang:
- (etwas OT): fhem kann ab sofort auch mit einem leeren cfg gestartet werden, bisher war noch mindestens "attr global modpath ." notwendig
- fhem.pl hat eine neue Option -t bekommen. Falls gesetzt, dann wird erst neben dem Argument eine Konfigurationsdatei gesucht (testname.cfg oder fhem.cfg), und danach die Testdatei per require ausgefuehrt. Das hat zur Folge, dass die Testdatei mit 1; beendet werden muss, und irgendwo ein exit(0) aufrufen muss.
- mit -t wird automatisch eine Instanz von FhemTestUtils (neu) definiert, was man zum Pruefen des FHEM-Logs oder Events verwenden kann. FhemTestUtils sammelt alle Logs/Events, und bietet zwei Funktionen an, um in der Liste jeweils mit einem Regexp suchen zu koennen.

Ich habe fuer MQTT2_SERVER zwei Beispiele eingecheckt: was Einfaches, was das Parsen direkt prueft:
# Simple test. NOTE: exit(0) is necessary
use strict;
use warnings;
use Test::More;

{ MQTT2_SERVER_ReadDebug($defs{m2s}, '0(12)(0)(5)helloworld') }
is(FhemTestUtils_gotLog("ERROR:.*bogus data"), 0, "Correct MQTT message");

FhemTestUtils_resetLogs();
{MQTT2_SERVER_ReadDebug($defs{m2s}, '(162)(50)(164)(252)(0).7c:2f:80:97:b0:98/GenericAc(130)(26)(212)4(0)(21)BLE2MQTT/OTA/')}
is(FhemTestUtils_gotLog("ERROR:.*bogus data"), 1, "Bogus message, as expected");

done_testing;
exit(0);
1;
und etwas Aufwendigeres, was per mosquitto_pub-Aufruf ein Geraet erzeugt:
# More complex test, with external program and delayed log/event checking
# Note: exit(0) must be called in the delayed code.
use strict;
use warnings;
use Test::More;

my $usage = `mosquitto_pub 2>&1`;
if(!$usage) { # mosquitto not installed
  ok(1);
  done_testing;
  exit(0);
}

fhem('"mosquitto_pub -i test -t hallo -m world"');
InternalTimer(time()+1, sub() {
  is(FhemTestUtils_gotLog(
        "autocreate: define MQTT2_test MQTT2_DEVICE test m2s"), 1,
        "autocreate log");
  is(FhemTestUtils_gotEvent("MQTT2_test:hallo: world"), 1,
        "autocreate event");
  done_testing;
  exit(0);
}, 0);

1;

prove wird eigentlich mit "prove --exec 'perl fhem.pl -t' t/*/*.t" aufgerufen, aber dank der (eingecheckten) .proverc kann man den Aufruf (wie oben) abkuerzen.

Und so schaut der Aufruf aus, wenn man den Test entwickelt:
% perl fhem.pl -t t/00_MQTT2_SERVER/01_autocreate.t
2020.05.13 12:42:24 1: Including t/00_MQTT2_SERVER/01_autocreate.cfg
2020.05.13 12:42:24 3: m2s: port 1883 opened
2020.05.13 12:42:24 1: Messages collected while initializing FHEM:SecurityCheck:
  m2s is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2020.05.13 12:42:24 0: Featurelevel: 6
2020.05.13 12:42:24 0: Server started with 3 defined entities (fhem.pl:21926/2020-05-13 perl:5.018002 os:darwin user:rudi pid:23070)
2020.05.13 12:42:24 2: autocreate: define MQTT2_test MQTT2_DEVICE test m2s
ok 1 - autocreate log
ok 2 - autocreate event
1..2

Titel: Antw:Unit Test?
Beitrag von: Sidey am 13 Mai 2020, 18:45:29
Das sieht ja schon sehr gut aus.

Werde ich mir näher ansehen und detaillierte Rückmeldung geben.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 13 Mai 2020, 20:41:18
Ich finde das super, endlich bewegt sich was.

Wenn ich einen Vorschlag machen könnte, dann wäre das die gesamte Testsuite nach t/FHEM zu schieben, also einen Level tiefer

t/FHEM/00_MQTT2_SERVER/...

Zum einen bewahrt das vor absehbaren Nameclashes (denn es kann nur ein t-Verzeichnis geben)
zum anderen kann man dann unter t/FHEM/* smoketests schreiben die für alle FHEM Module laufen.

Ach ja, letztere kann ich beisteuern, weil die bei mir - unter t/FHEM/* eh auf einen commit warten.
Titel: Antw:Unit Test?
Beitrag von: herrmannj am 13 Mai 2020, 20:59:51
Ich weiß nicht ob "man kann". Ich kann's nicht.

Ich finde das super, endlich bewegt sich was.
...
Ach ja, letztere kann ich beisteuern, weil die bei mir - unter t/FHEM/* eh auf einen commit warten.

Wie schnell sich die Zeiten doch ändern ;)

Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 13 Mai 2020, 21:11:14
Zitat
t/FHEM/00_MQTT2_SERVER/...
Kann ich gerne machen, wenn ich verstehe, wozu: was wollen wir sonst fuer Tests hier reinpacken?
Titel: Antw:Unit Test?
Beitrag von: Sidey am 13 Mai 2020, 23:00:30
Hi Rudi,

Super, ich habe mir die Implementierung angesehen. Das ist schon deutlich besser, als das was ich bisher hatte.
Vor allem die Idee sich in $logInform reinzuhängen. Echt klasse. Ich hab mir da immer einen abgemockt um die Logs abfangen zu können. ;)

Ein paar Anregungen / Fragen habe ich aber dennoch:

Deine Lösung mit "FhemTestUtils_gotLog" und "FhemTestUtils_gotEvent" hat mich zum grübeln gebracht.
Ich hätte es allerdings viel lieber, dass ich auf die Logs direkt zugreifen kann und das nicht eine Funktion für mich darin sucht.
Wieso? Weil ich dann einen Compare aus der Testsuit den Inhalt prüfen kann. Das muss man in anderen Datenstruktuen ebenfalls so anwenden und nebenbei bekommt man im Fehlerfall deutlich bessere Meldungen über was steht wirklich in dem Array und nach was wurde gesucht.

Ich schlage daher vor, Subs in das Modul aufzunehmen, die eine Referenz auf @logs und @events liefern.  (Siehe Patch).
Habe auch noch einen Kopierfehler im define korrigiert

Damit ließe sich, am Beispiel 00_parseMsg.t der Test wie folgt realisieren und vom Test her genauer steuern was in @logs stehen soll oder auch nicht:
use strict;
use warnings;
use Test2::V0;
use Test2::Tools::Compare qw{is bag};

my $fhemLogs=FhemTestUtils_getLogRef;


{ MQTT2_SERVER_ReadDebug($defs{m2s}, '0(12)(0)(5)helloworld') }
is( $fhemLogs,bag {item !match(qr/ERROR:.*bogus data/); end();}, 'Correct MQTT message');

FhemTestUtils_resetLogs();
{MQTT2_SERVER_ReadDebug($defs{m2s}, '(162)(50)(164)(252)(0).7c:2f:80:97:b0:98/GenericAc(130)(26)(212)4(0)(21)BLE2MQTT/OTA/')}
is( $fhemLogs,bag {item match(qr/ERROR:.*bogus data/); etc(); }, 'Correct MQTT message');

done_testing;
exit(0);
1;

Weiterhin, die Ausgabe der Logmedlungen auf der Konsole. Lassen sich diese abstellen?
Ich würde aus der Testsuit eher auf diag zurückgreifen wenn etwas nicht in Ordnung ist.


Ich habe auch festgestellt, dass sich alle Instanzen von FhemTestUtils das gleiche @logs und @events teilen.
Aktuell bin ich noch unsicher, ob man davon je mehr als eine gebrauchen könnte. Registriert man allerdings mehrere, so dürften die Logs mehrfach in @logs auftauchen und das den Test ggf. verfälschen, wenn man z.B. die Anzahl von Logmeldungen zählen würde?


Der in der Readme angegebene perl Aufruf klappt bei mir nicht:

perl fhem.pl t/00_MQTT2_SERVER/00_parseMsg.tmit
perl fhem.pl -t t/00_MQTT2_SERVER/00_parseMsg.t 
Klappt es.

Der Folgende Satz hat mich auch ein wenig zum Grübeln gebracht:
Zitat
Each test needs a config file, with is either fhem.cfg or testname.cfg
Wenn ich es richtig verstehe, dann kann ich eine "Default" Config in jedem Verzeichnis ablegen die aber fhem.cfg benannt werden muss. Hier habe ich keinen Gestaltungsspieltaum.
Möchte ich für einen Test eine Spezielle config, dann muss ich für <testname>.t eine config <testname>.cfg anlegen. Habe ich das so richtig verstanden?




Grüße Sidey

Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 13 Mai 2020, 23:10:23
Kann ich gerne machen, wenn ich verstehe, wozu: was wollen wir sonst fuer Tests hier reinpacken?

Tests für Module in einem lib Verzeichnis (siehe z.b. CoolTuxens "Automation/ShutterControl/*") - die dann unter t/Automation/* leben
dieses (bei mir bereits erfolgreich laufende) staticperl/AppImage Gespann ist doch sicher auch für FHEM künftig interessant
da wird es eine lib/* payload geben.

Prinzipiell geht es auch ohne, aber dann ist eben ein 00_MYSENSORS z.B. auf dem gleichen Level wie "Automation" und in Anbetracht
der Tatsache, dass unter 00_MYSENSORS hierarchisch keine Submodule sind  (also 00_MYSENSORS/Irgendwas.pm), ist es m.E.
nicht zielführend damit den Toplevel t-Namespace vollzukleistern.

Wie schnell sich die Zeiten doch ändern ;)

Nicht schnell genug, manche haben noch nicht gelernt richtig zu zitieren:

Zitat
zum anderen kann man dann unter t/FHEM/* smoketests schreiben die für alle FHEM Module laufen.

Ach ja, letztere kann ich beisteuern, weil die bei mir - unter t/FHEM/* eh auf einen commit warten.

https://de.wikipedia.org/wiki/Smoke_testing#Smoke_testing_in_der_Softwareentwicklung

"Echte tests" der xx_Name FHEM Module kann ich nicht schreiben, aber Rudolf kann's offensichtlich. Ist doch gut.
Die überhaupt erste Gelegenheit wo man mal komplementär (= in diesem Fall gemeinsam) an einem Strang ziehen
könnte.


Titel: Antw:Unit Test?
Beitrag von: Sidey am 13 Mai 2020, 23:10:50
Kann ich gerne machen, wenn ich verstehe, wozu: was wollen wir sonst fuer Tests hier reinpacken?

Ich nehme an, es geht hier darum, die Verzeichnisstrukturin t/ 1:1 aus dem Ordner fhem in dem fhem.pl liegt zu übernehmen.

Zumindest finde ich diesen Punkt einleuchtend, wenn eine Moduldatei in
fhem/FHEM liegt,
dass dann der test dazu auch in
t/FHEM/Modul liegt

Möchte irgendwann dann mal jemand einen Test für etwas schreiben, das in contrib liegt kommt der Test nach
t/contrib/
Und für die andere Diskussion, ob es ein
fhem/lib geben soll, wäre man dann auch gewappnet.


Ein schlagendes Argument hab ich noch, weil ich im übrigen auch schon genau mit dieser Struktur angefangen habe:
https://github.com/RFD-FHEM/RFFHEM/tree/dev-r35_xFSK_oo/t/FHEM/lib/SD_Protocols

Grüße Sidey
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 13 Mai 2020, 23:17:20
Ich nehme an, es geht hier darum, die Verzeichnisstrukturin t/ 1:1 aus dem Ordner fhem in dem fhem.pl liegt zu übernehmen.

Zumindest finde ich diesen Punkt einleuchtend, wenn eine Moduldatei in
fhem/FHEM liegt,
dass dann der test dazu auch in
t/FHEM/Modul liegt

Möchte irgendwann dann mal jemand einen Test für etwas schreiben, das in contrib liegt kommt der Test nach
t/contrib/
Und für die andere Diskussion, ob es ein
fhem/lib geben soll, wäre man dann auch gewappnet.

Jein.

Normalerweise gibt es diese 1:1 Relation nur zwischen lib und t

Ok, wir abstrahieren mal von "Normalerweise". Hier könnte man erstmal den Spagat machen und

FHEM
lib
t


so handhaben, als wäre FHEM ein Unterverzeichnis von lib. Vielleicht ist dem irgendwann so, vielleicht
bleibt das immer eine Spezialwurst. Bis dahin einfach:

lib -> t
FHEM -> t/FHEM


Sogar mit

t/contrib

könnte man operieren. Aber man sollte sich definitiv vor

t/lib

hüten, weil sonst ist man wieder im Pipi Langstrump-Land.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 13 Mai 2020, 23:33:14
@Sidey:
Zitat
Weil ich dann einen Compare aus der Testsuit den Inhalt prüfen kann.
Da FhemTestUtils_getLog das Ergebnnis von grep zurueckliefert, kann man mit .* die komplette Liste holen.

Zitat
Weiterhin, die Ausgabe der Logmedlungen auf der Konsole. Lassen sich diese abstellen?
Klar, ruf sie mit prove auf :)

Zitat
Aktuell bin ich noch unsicher, ob man davon je mehr als eine gebrauchen könnte.
Z.Zt. ist das kontraproduktiv, bin aber offen es zu aendern, wenn das sinnvoll sein koennte.

Zitat
Der in der Readme angegebene perl Aufruf klappt bei mir nicht:
Danke, habs korrigiert.


Zitat
Wenn ich es richtig verstehe, dann kann ich eine "Default" Config in jedem Verzeichnis ablegen die aber fhem.cfg benannt werden muss. Hier habe ich keinen Gestaltungsspieltaum.
Stimmt, irgendwo ist Schluss. Wobei ich auch noch nicht verstanden habe, warum du hier gestalten willst.


Zitat
Möchte ich für einen Test eine Spezielle config, dann muss ich für <testname>.t eine config <testname>.cfg anlegen. Habe ich das so richtig verstanden?
Ja, siehe t/00_MQTT2_SERVER/01_autocreate.cfg


@RichardCZ
Zitat
Prinzipiell geht es auch ohne, aber dann ist eben ein 00_MYSENSORS z.B. auf dem gleichen Level wie "Automation"
Verstanden, aber wenn man Modularisierung ernst nimmt dann sollte CoolTux & Co. sein Modul FHEM::XX::YY::ZZ nennen, womit das FHEM Verzeichnis wiederum im Weg stehen wuerde. Hast du auch fuer diese Variante eine Loesung ? :)
Ich mach schon mit, will es aber nur einmal umbenennen.
Titel: Antw:Unit Test?
Beitrag von: Sidey am 13 Mai 2020, 23:41:53
@Sidey:Da FhemTestUtils_getLog das Ergebnnis von grep zurueckliefert, kann man mit .* die komplette Liste holen.
Daran hatte ich nicht gedacht, aber wieso sollte ich ein grep auf etwas machen, wenn ich die komplette Liste 1:1 möchte?
Gibt es einen Nachteil sich die Referenz zu holen? Alternativ kann ich mich natürlich auch einfach in $loginform hängen. Bei den Events wird es halt ein bisschen Aufwändiger. :)

Klar, ruf sie mit prove auf :)

Hmm, dann bekomme ich aber meine diag Meldungen von der TestSuite auch nicht und prove -v liefert mir dann wieder alles :(
Ich hätte halt gerne nur die Meldungen aus der testsuite gehabt und nicht alles.  Machbar über eine Schalter oder nicht?
 
Grüße Sidey
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 13 Mai 2020, 23:49:52
@RichardCZVerstanden, aber wenn man Modularisierung ernst nimmt dann sollte CoolTux & Co. sein Modul FHEM::XX::YY::ZZ nennen, womit das FHEM Verzeichnis wiederum im Weg stehen wuerde. Hast du auch fuer diese Variante eine Loesung ? :)
Ich mach schon mit, will es aber nur einmal umbenennen.

Wenn CoolTux & Co. ihre Module FHEM::XX::YY::ZZ nennen hat das erstmal weniger mit Modularisierung als mit besagter Megalomanie zu tun.
Statt CPAN nennen wir es FHEM.  ;)
Der Punkt hinter Automation/* und nicht FHEM/Automation/* ist ja, dass man vielleicht wiederverwendbaren/generischen Code schreiben möchte der nicht FHEM-spezifisch ist.
Ok. ShuttersControl schafft das vielleicht noch nicht, aber so ein MySensors/* kommt sicher bald hin.

Ich sehe (was den Perl code anbelangt) relativ weit in die Zukunft. Und in dieser weiten Zukunft sehe ich keinen Grund diese Tests von t/FHEM/* wieder irgendwoanders hin zu schaufeln.
Selbst wenn alle FHEM Module irgendwann (in ferner Zukunft) nach lib/FHEM/*.pm wandern sollten, bleibt ja t/FHEM bestehen. Die Sache wird dann nur konsistenter.

Also ich sehe nicht mehr als die eine Umbenennung.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 13 Mai 2020, 23:55:56
Zitat
Gibt es einen Nachteil sich die Referenz zu holen?
Ja. Hier sind wir beim "ordentlichen" Programmierern, hier sind globale Variablen verpoent.
Und eine Referenz auf interne Datenstrukturen rauszugeben ist ungefaehr das Gleiche.

Zitat
Ich hätte halt gerne nur die Meldungen aus der testsuite gehabt und nicht alles.
Leute mit Extra-Wurst^H^H^Henschen muessen kreativ sein :)
attr global logfile /dev/null
oder
attr global verbose 0

Zitat
Also ich sehe nicht mehr als die eine Umbenennung.
Na dann: umbenannt.
Titel: Antw:Unit Test?
Beitrag von: CoolTux am 14 Mai 2020, 08:38:18
Da wir gerade über Verzeichnisstruktur reden. Ich persönlich hätte unter lib/FHEM/ jetzt eher FHEM interne Funktionen gesehen. Alle Commands zum Beispiel oder die Readings bzw Attr Sachen. Also jetzt nur so vor meinem geistigen Auge.
Die Module hätte ich spezifisch außerhalb von FHEM unter gebracht. Ich schreibe das um ein Verständnis von Wissenden zu bekommen wie sowas "besser" aussehen könnte.
Also

lib/FHEM/Automation/ShuttersControl......


oder


lib/Automation/ShuttersControl


Und auf was sollte man achten? ASC kann nicht ohne FHEM laufen also kommt es unter lib/FHEM/?

API Files wie zum Beispiel die von Weather laufen ohne FHEM (ok auch nicht ganz da HttpUtils verwendet wird) wo kommen die dann hin? lib/Weather/api/ oder lib/FEHM/Weather/api/?

Will mir halt so wie Rudi nur einmal Gedanken darüber machen müssen und dann nur noch loslegen wollen.
Titel: Antw:Unit Test?
Beitrag von: Sidey am 14 Mai 2020, 08:43:26
Meine Meinung dazu, aber ich bin nicht allwissend:

Alles was ohne FHEM läuft kommt nach lib/
und alles was nur mit FHEM läuft gehört nach
lib/FHEM/

Die Sache mit httputils ist ein gutes Beispiel um der Definition nachzugehen was es bedeutet ob etwas mit oder ohne FHEM läuft.

Um da irgendwie einen Mittelweg zu finden, wie wäre es mit alles was nur im Kontext fhem.pl lauffähig ist gehört nach lib/FHEM

Httputils läuft bestenfalls auch ohne die fhem.pl und lässt sich via use einbinden :)


Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: CoolTux am 14 Mai 2020, 08:48:02
Httputils läuft bestenfalls auch ohne die fhem.pl und lässt sich via use einbinden :)

Leider Nein. HttpUtils verwendet auch fhem.pl interne Routinen. Wie stark die Abhängigkeit ist vermag ich gerade nicht zu sagen.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 14 Mai 2020, 12:05:50
Ja. Hier sind wir beim "ordentlichen" Programmierern, hier sind globale Variablen verpoent.

Globale Variablen kann man sich in einem Arduino-Sketch erlauben, ansonsten sind die
überall verpönt.

Was man machen kann, was ich auch für HoBo plane - sobald der 48h Tag eingeführt wird - wäre
ein Singleton-Objekt a.k.a. "God Object", welches eine globalgalaktische Datenstruktur vorhält
die man von überallher anzapfen kann.

Im Idealfall also ein lib/HoBo/Globals.pm

was das Zeug enthält was jetzt in use vars in fhem.pl/hobo.pl fleucht.
Das würde erstmal main:: volkleistern wie gehabt - also kompatibel, aber man könnte
Schritt für Schritt getter/setter anbieten und irgendwann so wieder zu einem Normalzustand gelangen.



Danke für die Umbenamsung, ich assimiliere das mal im HoBo und schmeiss das in die CI automated Tests rein.
Mal schauen was bei rauskommt.
Titel: Antw:Unit Test?
Beitrag von: justme1968 am 14 Mai 2020, 15:31:38
anbei ein beispiel für einen aller ersten test für parseParams t/FHEM/00_fhem.pl/00_parseParams.t:

Zitat
# Simple test. NOTE: exit(0) is necessary
use strict;
use warnings;
use Test::More;

my $cmd = 'set name test1 test2=abc test3 "test4 test4" test5="test5 test5" test6=\'test6=test6\' test7= test8="\'" test9=\'"\' {my $x = "abc"} test10={ { my $abc ="xyz" } }';

my $expected_a = [ 'set', 'name', 'test1', 'test3', 'test4 test4', '{my $x = "abc"}' ];
my $expected_h = {
           'test2' => 'abc',
           'test5' => 'test5 test5',
           'test6' => 'test6=test6',
           'test7' => '',
           'test8' => '\'',
           'test9' => '"',
          'test10' => '{ { my $abc ="xyz" } }'
        };


my ($a,$h) = parseParams( $cmd );

is_deeply($h, $expected_h, "parseParams hash");
is_deeply($a, $expected_a, "parseParams array");

done_testing;
exit(0);
1;


was mir aufgefallen ist:

für den test oben braucht es kein config file. wenn man keins anlegt gibt es beim aufruf über perl fhem.pl -t t/FHEM/00_fhem.pl/00_parseParams.t alle möglichen meldungen. ein leeres config file reicht um das zu verhindern. aber ganz ohne wäre sauberer.

wie schaut es mit der 'hoheit' über das t/FHEM verzeichnis aus? d.h. wer darf einchecken?
- jeder für eigene module?
- was ist mit fremden modulen und neuen tests?


wie würde es aussehen wenn man in parseParams noch mehr testen möchte?
- alles ins gleiche 00_parseParams.t file?
- oder mehrerer XX_parseParams.t files?


wenn man für den -t <param> aufruf aus versehen ein directory als parameter angibt beendet sich das ganze nicht. vorschlag:
- entweder prüfen und beenden
- oder automatisch alle *.t darin ausführen ?
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 14 Mai 2020, 18:08:29
Zitat
anbei ein beispiel für einen aller ersten test für parseParams t/FHEM/00_fhem.pl/00_parseParams.t:
Habs eingecheckt.

Zitat
ein leeres config file reicht um das zu verhindern. aber ganz ohne wäre sauberer.
Stimmt, aber der Aufwand ist minimal und der Workaround-Code dafuer in fhem.pl ist mir zu viel.

Zitat
wie schaut es mit der 'hoheit' über das t/FHEM verzeichnis aus? d.h. wer darf einchecken?
Ich wuerde sagen, das ist identisch zu Modul-Hoheit.

Zitat
wie würde es aussehen wenn man in parseParams noch mehr testen möchte?
In diesem Fall wuerde ich alle Tests zu parseParams in die gleiche Datei stecken, weil fuer mich eine einzige Funktion ueber mehrere TestDateien zu testen zu bunt erscheint. Ist aber kein Gesetz, nur Praeferenz.


Zitat
wenn man für den -t <param> aufruf aus versehen ein directory als parameter angibt beendet sich das ganze nicht.
Habe Pruefung & Beenden eingebaut
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 15 Mai 2020, 23:16:12
Kurze technische Zwischenfrage: Werden die Prototypes nicht langsam unübersichtlich?

sub evalStateFormat($);
sub execFhemTestFile();
sub fhem($@);
sub fhemTimeGm($$$$$$);
sub fhemTimeLocal($$$$$$);
sub fhemTzOffset($);
sub getAllAttr($;$);
sub getAllGets($;$);
sub getAllSets($;$);
sub getPawList($);
sub getUniqueId();
sub hashKeyRename($$$);
sub json2nameValue($;$$);
sub json2reading($$;$$$);
sub latin1ToUtf8($);
sub myrename($$$);
sub notifyRegexpChanged($$);
sub parseParams($;$$$);
sub prepareFhemTestFile();
sub execFhemTestFile();
sub perlSyntaxCheck($%);
sub readingsBeginUpdate($);
Titel: Antw:Unit Test?
Beitrag von: Sidey am 16 Mai 2020, 10:37:37


anbei ein beispiel für einen aller ersten test für parseParams t/FHEM/00_fhem.pl/00_parseParams.t:

Hi,

Kurzer Hinweis von mir.
Schaut euch die Test2 Suite an.
Ich kann es nur empfehlen. Es liefert bessere Möglichkeiten Datenstrukturen zu vergleichen und bietet auch hilfreiche Ausgaben wenn etwas nicht passt.

Ich selbst habe auch mit Test::Mode begonnen, bin dann aber auch schnell an die Grenzen gestoßen. Die Test2 Suite ist da deutlich flexibler und umfangreicher.

Gruß Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: Sidey am 16 Mai 2020, 10:52:50
Moin,

Nachdem ich mich ein wenig weiter mit dem Thema beschäftigt habe, wollte ich auch mal schauen wie leicht ich einen meiner bestehenden Tests migrieren kann.

So ca. 4 Zeilen Code musste ich anpassen und dann lief der Test schon, was erfreulich ist :)

Allerdings haben die Ergebnisse nicht gepasst und ich kam ins grübeln, worin der Unterschied besteht.

Am Ende ist mir dann aufgefallen, dass es ein Problem des Zeitpunktes ist zu dem der Test läuft.
Er läuft ja direkt nachdem die Initialisierung abgeschlossen ist. Beim UnitTest Modul hatte ich mit einer Verzögerung gearbeitet.

Vermutlich habe ich hier in der Vergangenheit technische Schulden aufgebaut. Ich weiß auch nicht mehr exakt wieso, aber irgendwie musste ich sicher gehen, Attribute auswerten zu können um die passende Konfiguration herstellen zu können. Das ist im Define ja nicht sicher gestellt. Wie soll das auch gehen.

Meine Definition ist nach Abschluss vom define somit nicht voll einsatzbereit. Das ganze dauert dann noch mal etwa 1 Sekunde, über einen internalTimer, bis alles abgearbeitet ist.
Keine top Lösung, funktioniert aber bislang.

Nun viel mir ein, dass ich in Rudis Beispiel etwas gesehen hatte, wie ein Test verzögert wird:

https://svn.fhem.de/trac/browser/trunk/fhem/t/FHEM/00_MQTT2_SERVER/01_autocreate.t

Mir erschien das zunächst auch logisch.
Es funktioniert aber bei mir nicht, in dem der eigentliche Test über einen Internal Timer verzögert wird. :-(
Entweder liegt es an mir oder es kann nicht funktionieren. Funktioniert denn dieses Vorgehen bei dir Rudi? Ich habe kein mqtt Client installiert und wenn ich mir das überlege, dann wird an prove schon ein Ergebnis geliefert, bevor der internal Timer laufen konnte, weil das Modul ja am Ende ankommt bevor der Timer startet.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 16 Mai 2020, 11:22:31
Ich verstehe die Frage nicht, und rate: hast Du exit(0) zu frueh ausgefuehrt?
Mein Test funktioniert, habs gerade kontrolliert.
Titel: Antw:Unit Test?
Beitrag von: Sidey am 16 Mai 2020, 21:50:58
Ich verstehe die Frage nicht, und rate: hast Du exit(0) zu frueh ausgefuehrt?
Mein Test funktioniert, habs gerade kontrolliert.

Nein, daran lag es nicht. Es lag am fehlenden proverc. Das wird über ein FHEM Update ja nicht mit ausgeliefert und da wo ich getestet habe, gab es das noch nicht. Funktioniert also doch wie gewünscht. :)
Titel: Antw:Unit Test?
Beitrag von: betateilchen am 17 Mai 2020, 10:40:09
Nein, daran lag es nicht. Es lag am fehlenden proverc. Das wird über ein FHEM Update ja nicht mit ausgeliefert

Wer, wie ich, sein FHEM über SVN updated, bekommt das sehr wohl mit ausgeliefert.
Die gesamte Struktur beim Update sieht in diesem Fall im Moment sehr unübersichtlich aus.

Titel: Antw:Unit Test?
Beitrag von: Sidey am 17 Mai 2020, 10:53:55
Hallo betateilchen,

Danke für die Info.
Bei mir lag die Datei nicht , seltsam denn ohne Update kommt man ja auch nicht an die Erweiterungen aus der fhem.pl

Das muss dann an irgendeiner Besonderheit bei mir liegen.

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 31 Mai 2020, 11:49:05
Ich versuche gerade das FhemTestUtils Framework zu nutzen - macht ja sonst niemand - komme aber nicht so recht auf einen grünen Zweig.

Plan war/ist "define" Smoketests zu veranstalten für alle Module.

Naiv+Cargo Cult dachte ich, ich gehe genauso vor wie im MQTT Beispiel


define AC ArduCounter /dev/tty0
define ac autocreate


und dann Log checken. Während jedoch MQTT das hier macht

2020.05.31 11:40:23 0: Featurelevel: 6
2020.05.31 11:40:23 0: Server started with 3 defined entities (hobo.pl:99999/2020-04-11 perl:5.030001 os:linux user:root pid:841310)
2020.05.31 11:40:23 2: autocreate: define MQTT2_test MQTT2_DEVICE test m2s
$VAR1 = [
          '2020.05.31 11:40:23 2 : autocreate: define MQTT2_test MQTT2_DEVICE test m2s'
        ];

(der VAR1 ist ein Dumper des FhemTestUtils Logs für meine Kontrolle),

Macht mein ArduCounter Versuch das hier:

2020.05.31 11:42:04 3: AC: Notify called with events: INITIALIZED, open device and set timer to send hello to device
2020.05.31 11:42:04 3: Opening AC device /dev/tty0
2020.05.31 11:42:04 3: Setting AC serial parameters to 38400,8,N,1
2020.05.31 11:42:04 3: AC device opened
2020.05.31 11:42:04 0: Featurelevel: 6
2020.05.31 11:42:04 0: Server started with 3 defined entities (hobo.pl:99999/2020-04-11 perl:5.030001 os:linux user:root pid:841369)
$VAR1 = [];

Sieht so aus als kämen die Logs "zu früh". Dabei ist es vollkommen egal ob ich den eigentlichen Test immediate, oder im Delayed Code mache.

Also direkt is(...) oder InternalTimer(... is(...) ) im .t File.



By the way: Das hier sind keine Unit, sondern Funktionstests -> und gerade als solche sind sie wertvoll. Vorschnell vielleicht (weil man zunächst eine gute Unit-Testsuite haben sollte), aber definitiv wertvoll.

Also bitte Vorschläge, wie ich meinen Plan "mal eben alle/so viele wie möglich Module via define zu checken" umsetzen könnte.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 31 Mai 2020, 12:07:42
Was zum Erfolg führt, aber für meinen Geschmack ein wenig von hinten durch die Brust ins Auge (bzw FHEM Klärgrube-Freistil) ist:

t/FHEM/00_define_smoke.cfg

define AC1 ArduCounter /dev/tty0

dann in t/FHEM/00_define_smoke.t

fhem('define AC1 ArduCounter /dev/tty0');

dann kommt

2020.05.31 12:03:05 0: Server started with 3 defined entities (hobo.pl:99999/2020-04-11 perl:5.030001 os:linux user:root pid:842177)
2020.05.31 12:03:05 3: define AC1 ArduCounter /dev/tty0 : AC1 already defined, delete it first
$VAR1 = [
          '2020.05.31 12:03:05 3 : define AC1 ArduCounter /dev/tty0 : AC1 already defined, delete it first'
        ];

Naja ... das könnte ich testen. Aber kommt euch das nicht vor wie "die Stimme aus dem Grab über Bande gespielt"?


Titel: Antw:Unit Test?
Beitrag von: justme1968 am 31 Mai 2020, 12:29:43
nein. das führt nicht zum erfolg. s.u.

wie immer ist etwas hintergrund wissen nötig:
es gibt mindestens drei varianten wie module ihren start organisieren:
- direkt im define wird alles abgearbeitet
  das ist die 'älteste' methode und funktioniert wenn das modul keine weiteren abhängigkeiten
  imhinblick auf andere device (iodev), gesetzte attribute hat

- im define wird ein internal timer gestartet und die initialisierung wird nach ablauf des timers gemacht

- das modul wertet $init_done und das globale INITIALIZED event aus
  - der benutzer legt zur laufzeit ein neues device von hand an -> $init_done ist gesetzt
    -> die initialisierung erfolgt sofort
  - das device wird beim fhem start aus dem gespeicherten zustand (define, attribute) angelegt
     -> $init_done ist noch nicht gesetzt -> es wird auf das INITIALIZED event gewartet
     -> der gespeicherte zustand ist komplett wieder hergestellt -> danach wird alles initialisiert

bei variante 1 kommt würden die log eintrage vor der 'Server started' zeile kommen. diese variante ist aber problematisch sobald es abhänigkeiten gibt.

variante 2 ist eigentlich nicht zu empfehlen weil niemand weiss ob der zeitraum reicht und ausserdem abhängigkeiten selbst dann nicht passen wenn das andere device die gleiche variante verwendet und die zeiten nicht passen

variante 3 ist die zu empfehlende wenn es abhängigkeiten gibt.

ArduCounter scheint variante 1 und 3 zu mischen. und es gibt Meldungen die vor der 'Server started...' zeile kommen und welche die danach kommen würden.


umgekehrt heisst das aber auch das man nicht einfach jedes modul auf die gleiche art testen kann da sich das start verhalten unterscheidet und man ausserdem eigentlich auch noch 'manuelles' define zur laufzeit und das define aus dem start vorgang abdecken muss da sich das verhalten auch hier unterscheiden kann. aber nur entweder oder. nicht in .cfg und in .t gleichzeitig. damit testet du nur ob das define kommando wie vorgesehen einen fehler liefert wenn du den gleichen namen mehrfach verwendest aber nichts auf device ebene.


es bedeutet ausserdem das man zumindest für variante 2 und 3 dafür sorgen muss das die fhem main loop zumindest ein klein wenig gelaufen ist. bevor man ins log schaut und den test beendet.





Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 31 Mai 2020, 12:43:36
Danke für die Hinweise.

Dass man nicht jedes Modul über den gleichen Kamm scheren kann, habe ich vermutet und ist soweit ok - das Ziel ist das Ziel.
Ich habe kein Problem damit mal (mühsam) die (individuellen) Tests für die Module zu schreiben. Denn dann hat man wenigstens
einen Harnisch.

Aber je mehr ich probiere, desto bunter wird der Zoo. Dabei gehe ich stur nach commandref vor:

fhem('define ASC AutoShuttersControl');

Sieht wie Variante 3 aus,

2020.05.31 12:33:14 0: Server started with 2 defined entities (hobo.pl:99999/2020-04-11 perl:5.030001 os:linux user:root pid:843417)
2020.05.31 12:33:14 3: ASC: unknown attribute icon. Type 'attr ASC ?' for a detailed list.
2020.05.31 12:33:14 3: ASC: unknown attribute devStateIcon. Type 'attr ASC ?' for a detailed list.
2020.05.31 12:33:14 3: AutoShuttersControl (ASC) - defined
$VAR1 = [
          '2020.05.31 12:33:14 3 : ASC: unknown attribute icon. Type \'attr ASC ?\' for a detailed list.',
          '2020.05.31 12:33:14 3 : ASC: unknown attribute devStateIcon. Type \'attr ASC ?\' for a detailed list.',
          '2020.05.31 12:33:14 3 : AutoShuttersControl (ASC) - defined'
        ];

Es kommt zum "richtigen" Zeitpunkt, wenngleich ich jetzt nicht erwartet hätte so viele Fehler um die Ohren gewatscht zu bekommen.

Ok, ich stocher' mal rum bei den einzelnen Modulen um einGefühl dafür zu bekommen welches wie startet.
Titel: Antw:Unit Test?
Beitrag von: justme1968 am 31 Mai 2020, 12:56:53
die fehler kommt weil ASC vermutlich nicht vorsieht ohne fhemweb zu laufen. dort kommen die attribute icon und devStateIcon her.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 31 Mai 2020, 13:04:34
Variante 2 mit InternalTimer(1, sub{}, 0) ist die einfachere Variante der global:INITIALIZED Event-Auswertung, weil die eingetragenen Timer-Routinen erst nach Einlesen aller Config-Files abgearbeitet werden. Ich ziehe diese Methode global:INITIALIZED inzwischen vor. Beides dient dazu, dass die Initialisierung mit Kenntnis aller Attribute und Readings erfolgt.

Zu den Tests:
- define legt ein Geraet an. Wann es vollstaendig initialisiert/"betriebsbereit" ist, kann der Autor mit den genannten Methoden entscheiden.
- autocreate erzeugt bei den voreingestellten verbose 3 eine Ausgabe, und define ArduCounter nicht. Warum wird das als Fehler gewertet?
- wenn ich pruefen will, ob ein Modul keine Syntaxfehler hat, dann wuerde ich nach dem define testen, ob das Geraet angelegt ist.
- icon und devStateIcon sind nur fuer FHEMWEB relevant, deswegen muss vorher eine FHEMWEB Instanz definiert sein, was wiederum per userattr diese Attribute aktiviert.

P.S. Kommentare ala Klaergrube nerven mich, und fuehren mittelfristig dazu, dass ich meine Hilfe nicht anbiete.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 31 Mai 2020, 14:36:35
https://gl.petatech.eu/root/HomeBot/-/jobs/168 (s.u. nun 8 Funktionstests)

https://gl.petatech.eu/root/HomeBot/-/commit/1cefbb3a753d56d65ef2801a06918bb7f852774b#43b584c479f6e29dee48f9676c72edae39725b16

a.k.a. "Schwalbe - noch kein Sommer", aber trotzdem nett - finde ich.

übrigens: einer von denen braucht Date::Time - hat der Test ergeben.


PS: Mich nervt auch so manches. z.B wenn  neuer Code 2020 a.D. so aussieht wie
"das war schon 2005 nicht so toll". Da frage ich mich dann auch ob es die vergebliche
Liebesmüh' wert ist.

And that's why we can't have nice things.

Sehr schade eigentlich.



Modifikationen an FhemTestUtils:

sub FhemTestUtils_gotLog {
    my $arg   = shift;
    my $reset = shift // 0;

    my $back = grep m{$arg}, @logs;

    @logs = () if ($reset);

    return $back;
}

2. Parameter macht einen Log Reset. Default: kein Reset.

Da FhemTestUtils_gotLog einen Wahrheitswert zurückliefert, kann man im Testfile auch ok(...) statt is(..., 1) verwenden.


ElsnerWS verhält sich sehr fragil beim Define:

2020.05.31 16:00:16 1: PERL WARNING: Use of uninitialized value $d in hash element at hobo.pl line 3221.
2020.05.31 16:00:16 1: PERL WARNING: Use of uninitialized value $autocreateName in hash element at ./FHEM/00_ElsnerWS.pm line 121.
2020.05.31 16:00:16 2: ElsnerWS define FileLog_EWS FileLog ./log/EWS-%Y-%m.log EWS
2020.05.31 16:00:16 1: PERL WARNING: Use of uninitialized value $autocreateName in hash element at ./FHEM/00_ElsnerWS.pm line 144.
2020.05.31 16:00:16 2: ElsnerWS define SVG_EWS SVG FileLog_EWS:ElsnerWS:CURRENT
2020.05.31 16:00:16 1: PERL WARNING: Use of uninitialized value $FW_gplotdir in concatenation (.) or string at ./FHEM/98_SVG.pm line 141.
2020.05.31 16:00:16 1: PERL WARNING: Use of uninitialized value $FW_gplotdir in concatenation (.) or string at ./FHEM/98_SVG.pm line 144.
2020.05.31 16:00:16 2: ElsnerWS ERROR: set SVG_EWS copyGplotFile: Can't open /ElsnerWS.gplot: No such file or directory
2020.05.31 16:00:16 1: define EWS ElsnerWS comtype=rs485 devicename=/dev/tty0: Can't open /ElsnerWS.gplot: No such file or directory
2020.05.31 16:00:16 3: define EWS ElsnerWS comtype=rs485 devicename=/dev/tty0 : Can't open /ElsnerWS.gplot: No such file or directory

Ich gehe natürlich davon aus, dass das im Lokalkolorit ja überhaupt kein Problem darstellt, aber unter normalen Umständen ("da draussen") stört sowas.



Reiche Ernte:

FBAHAHTTP macht überhaupt keinen Mucks im Log beim define. Nichtmal wenn ich ihm die lokale Fritzbox anbiete und auch nicht nach X Sekunden.

define FHZ FHZ /dev/tty0

kämpft ein wenig

2020.05.31 16:19:32 3: FHZ opening FHZ device /dev/tty0
2020.05.31 16:19:32 3: FHZ opened FHZ device /dev/tty0
2020.05.31 16:19:33 1: Trying again get FHZ init2 (2 out of 3)
2020.05.31 16:19:34 1: Trying again get FHZ init2 (3 out of 3)
2020.05.31 16:19:37 1: Trying again get FHZ serial (2 out of 3)
2020.05.31 16:19:38 1: Trying again get FHZ serial (3 out of 3)

Dann faltet sich alles fatal:

Can't use an undefined value as an ARRAY reference at hobo.pl line 1558.
Compilation failed in require at hobo.pl line 4651.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 29 just after 5.

Gut, das passiert mir zwar in HoBo, aber ich würde wetten das passiert in FHEM auch. In DoSet:

$arg = join(" ", @args) if (!@{$hash->{CHANGED}});
Ich gehe davon aus $hash->{CHANGED} ist in dem Fall (noch) keine Arrayref.
Ha! Was ein wenig defensives Programmieren doch ausmachen kann:

        $hash->{CHANGED} //= [];
        $arg = join(" ", @args) if (!@{$hash->{CHANGED}});

=> Und der Test läuft durch.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 31 Mai 2020, 17:57:17
Zitat
Modifikationen an FhemTestUtils:
Man verliert dadurch die Moeglichkeit eine Liste (z.Bsp den kompletten Log) zurueckzuliefern.

Zitat
FBAHAHTTP macht überhaupt keinen Mucks im Log beim define.
Bei mir steht "MISSING: attr fbaha fritzbox-user" im Log und im STATE.

Zitat
Dann faltet sich alles fatal:
Bei mir faltet sich nix, muss an hobo.pl liegen.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 31 Mai 2020, 19:33:57
Na gut, dann eben List-Kontext.

https://gl.petatech.eu/root/HomeBot/-/commit/47d6819b8451a7fa1e6ceaf1fb8ea73dd054e43f

Du hast Recht, fhem.pl faltet sich nicht, werde ich Ursachenforschung bei HoBo betreiben.
Allerdings macht auch bei mir fhem.pl keinen Mucks bei FBAHAHTTP. Musst ein noch magischeres fhem.pl haben als auf SVN verfügbar.

perl fhem.pl -t t/FHEM/00_smoke_define.t

...
2020.05.31 19:28:35 3: Opening FB1 device 127.0.0.1:2002
2020.05.31 19:28:35 1: FB1: Can't connect to 127.0.0.1:2002: Connection refused
2020.05.31 19:28:35 3: FHZ opening FHZ device /dev/tty0
2020.05.31 19:28:35 3: FHZ opened FHZ device /dev/tty0
2020.05.31 19:28:36 1: Trying again get FHZ init2 (2 out of 3)
2020.05.31 19:28:37 1: Trying again get FHZ init2 (3 out of 3)
2020.05.31 19:28:40 1: Trying again get FHZ serial (2 out of 3)
2020.05.31 19:28:41 1: Trying again get FHZ serial (3 out of 3)
2020.05.31 19:28:43 3: WEB: port 8084 opened
...
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 01 Juni 2020, 21:19:06
https://gl.petatech.eu/root/HomeBot/-/jobs/173

es geht langsam voran. Den Bug in HoBo mit FHZ define habe ich behoben - da war ich etwas übereifrig beim Optimieren.

Bisheriges Ergebnis der Tests:

ElsnerWS - kotzt viel zu viele Warnings, aber bleibt am Leben
FBAHAHTTP - bleibt still
LIRC - couldn't connect to Lirc::Client=HASH(0x5557efa5f558)->dev: No such file or directory at ./FHEM/00_LIRC.pm line 44

Die anderen - siehe https://gl.petatech.eu/root/HomeBot/-/blob/master/t/FHEM/00_smoke_define.t - sind ok.



@Rudolf

Ich würde vorschlagen/bitten, dass Deine Tests unabhängig voneinander laufen können, sonst kann man sie nicht parallelisieren.

prove --exec 'perl hobo.pl -t' -r t/FHEM/
t/FHEM/00_MQTT2_SERVER/00_parseMsg.t .... ok   
t/FHEM/00_MQTT2_SERVER/01_autocreate.t .. ok   
t/FHEM/00_smoke_define.t ................ ok   
t/FHEM/fhem.pl/00_parseParams.t ......... ok   
All tests successful.
Files=4, Tests=20, 19 wallclock secs ( 0.03 usr  0.00 sys +  0.70 cusr  0.09 csys =  0.82 CPU)
Result: PASS

tut, aber

# prove --exec 'perl hobo.pl -t' -r -j 2 t/FHEM/
t/FHEM/00_MQTT2_SERVER/01_autocreate.t .. Dubious, test returned 1 (wstat 256, 0x100)
No subtests run
t/FHEM/00_MQTT2_SERVER/00_parseMsg.t .... ok                           
t/FHEM/fhem.pl/00_parseParams.t ......... ok                           
t/FHEM/00_smoke_define.t ................ ok   

Test Summary Report
-------------------
t/FHEM/00_MQTT2_SERVER/01_autocreate.t (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=4, Tests=18, 18 wallclock secs ( 0.02 usr  0.01 sys +  0.68 cusr  0.05 csys =  0.76 CPU)
Result: FAIL

tut nicht. Wenn ich wirklich mal 500 Module testen will bei jedem commit, sollten da etliche test-Threads parallel laufen.
Schon jetzt dauern die paar define smoketests 20 Sekunden - die meiste Zeit wartet man auf timeouts.

Falls Du also in einer .t-Datei den mosquitto startest, den laufenden mosquitto aber in der anderen test-Datei brauchst, dann besser diese beiden .t Files zusammenzufassen.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 02 Juni 2020, 12:04:40
Zitat
FBAHAHTTP - bleibt still
Bitte mein Kommentar von frueher beachten.

Zitat
Ich würde vorschlagen/bitten, dass Deine Tests unabhängig voneinander laufen können, sonst kann man sie nicht parallelisieren.
Bei z.Zt. genau 1 Beitrag (00_parseParams.t) sehe ich die Notwendigkeit nicht als dringend.
Ich habe trotzdem in FHEM/00_MQTT2_SERVER/fhem.cfg den Port auf 1884 verlegt, damit laeuft der Test bei mir auch mit prove -j 2 durch.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 02 Juni 2020, 12:46:33
Bitte mein Kommentar von frueher beachten.

Woraufhin ich antwortete

Zitat
Allerdings macht auch bei mir fhem.pl keinen Mucks bei FBAHAHTTP. Musst ein noch magischeres fhem.pl haben als auf SVN verfügbar.

Ebenso machen Neuron, MAXLAN und MYSENSORS keinen Mucks

OWX_ASYNC meint unbedingt nochmal den Log3 Prototypen erwähnen zu müssen.

2020.06.02 12:29:28 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/00_OWX_ASYNC.pm line 94

Er ist zwar schon in fhem.pl (im gleichen Namespace also) definiert, aber warum nicht...
Hier wirst Du natürlich sagen "Ich habe das Problem in FHEM nicht". Ja klar  :)
Aber ich erinnere an Deine Einlassung hinsichtlich Aversion gegenüber Code-Dupes.

Zitat
Bei z.Zt. genau 1 Beitrag (00_parseParams.t) sehe ich die Notwendigkeit nicht als dringend.
Ich habe trotzdem in FHEM/00_MQTT2_SERVER/fhem.cfg den Port auf 1884 verlegt, damit laeuft der Test bei mir auch mit prove -j 2 durch.

Danke.  Feel free die Smoketests von HoBo zu verwenden. Dann kannst Du schon von 2 Beiträgen sprechen.

Mittlerweile sind die smoketests auch schön data-driven.  8)

Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 02 Juni 2020, 12:52:11
Zitat
    Allerdings macht auch bei mir fhem.pl keinen Mucks bei FBAHAHTTP. Musst ein noch magischeres fhem.pl haben als auf SVN verfügbar.
Bei mir macht "define FBAHAHTTP" auch kein Mucks, und das ist auch ok so.
Wenn ich pruefen will, ob das FBAHAHTTP Modul kein Sytaxfehler hat, dann wuerde ich nach dem define pruefen, ob das Geraet angelegt ist.

00_OWX_ASYNC.pm muss von seinem Maintainer angepasst werden (oder auch nicht).
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 02 Juni 2020, 13:39:50
Bei mir macht "define FBAHAHTTP" auch kein Mucks, und das ist auch ok so.
Wenn ich pruefen will, ob das FBAHAHTTP Modul kein Sytaxfehler hat, dann wuerde ich nach dem define pruefen, ob das Geraet angelegt ist.

Ok, kannst Du ein Beispiel machen? Ich mache dann gerne die 00_smoke_exist.t Fleißarbeit.

Das sich abzeichnende Problem wird wohl sein, dass man einigen Modulen ein Device wird vorgaukeln müssen. Dieses Mocking wird schweißtreibend, deswegen schiebe ich es noch vor mir her.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 02 Juni 2020, 16:13:51
Zitat
Ok, kannst Du ein Beispiel machen?
Fuer Folgendes muessen die define Argumente korrekt sein, und je nach Modul auch das Geraet erreichbar, Passwort/etc gesetzt sein:
is(defined($defs{<NAME>}), 1, "instance defined");
Die Instanz kann entweder in fhem.cfg definiert werden oder in der Testdatei mit fhem('define <NAME> ModulName Parameter')


Pruefen ob ein Modul geladen werden konnte (nur Syntax-Check):
is(CommandReload(undef, "98_dummy.pm"), undef, "dummy loaded");
Zitat
Das sich abzeichnende Problem wird wohl sein, dass man einigen Modulen ein Device wird vorgaukeln müssen.
Etliche Module unterstuetzten ein test/debug Modus ohne Hardware, z.Bsp. CUL mit "define CUL CUL none 1234".
Aehnlich ist es bei FHZ, ZWDongle, ZWCUL, FBAHA*, KM271, etc.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 02 Juni 2020, 19:43:14
Ok, wühle ich mich mal durch. Danke.

Anderweitiges Durchwühlen brachte:

2020.06.02 19:37:13 0: Bareword "NULL" not allowed while "strict subs" in use at ./FHEM/00_SIGNALduino.pm line 4982.

->

            my $osv2byte = "";
            $osv2byte = NULL;
            $osv2byte = substr( $bitData, $idx, 16 );

Zeile 5049 ähnlich

            my $osv3nibble = "";
            $osv3nibble = NULL;
            $osv3nibble = substr( $bitData, $idx, 4 );

Das kann doch noch nie funktioniert haben - oder?
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 03 Juni 2020, 13:18:29
Das sieht alles ziemlich gut aus. Also im Sinne von: Da findet man einiges.


# Looks like you failed 70 tests of 566.
...
# Looks like you failed 58 tests of 566.
...
# Looks like you failed 43 tests of 566.
...
# Looks like you failed 36 tests of 566.

Nagut...  Interesse an den Ergebnissen? Oder soll ich den betreffenden Modulen erstmal ein Morphium-Pflaster verpassen?

Also so Sachen wie

2020.06.03 13:09:00 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE (?:[^{}]++|(?1))*})/ at ./FHEM/70_MEDIAPORTAL.pm line 570.
2020.06.03 13:09:00 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/[ \r\n]*({ <-- HERE (?:[^{}]++|(?1))*})[ \r\n]*/ at ./FHEM/70_MEDIAPORTAL.pm line 576.

oder

2020.06.03 13:09:00 1: PERL WARNING: Subroutine dq redefined at ./FHEM/70_PIONEERAVR.pm line 4138.

2020.06.03 13:08:59 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 1140.

2020.06.03 13:08:59 1: PERL WARNING: Constant subroutine main::SHIFT redefined at /opt/perlbrew/perls/perl-5.30.1/lib/5.30.1/constant.pm line 171.
(37_harmony.pm)

Ein Problem habe ich bei 21_OWTEMP.pm

'Can't locate OW.pm in @INC (you may need to install the OW module)

und keine Ahnung wo ich OW.pm finden könnte. Weder gibt es eine Datei OW.pm in FHEM (oder auf CPAN), noch finde ich ein "package OW" in irgendeiner Datei erwähnt.

Naja und dann och so ca. 30 weitere Module die Sperenzchen machen.
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 03 Juni 2020, 14:52:07
Zitat
Nagut...  Interesse an den Ergebnissen?
Ich faende es sinnvoll die Ergebnisse hier zu zeigen, dann koennte der Maintainer entscheiden, ob er was fixen will oder nicht.
Zu OWTEMP steht in Wiki was von veraltet/abzuraten, aber wenn es gar nicht funktioniert, dann sollte es aus dem FHEM Verzeichnis entfernt werden.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 03 Juni 2020, 15:54:26
Ich faende es sinnvoll die Ergebnisse hier zu zeigen, dann koennte der Maintainer entscheiden, ob er was fixen will oder nicht.
Zu OWTEMP steht in Wiki was von veraltet/abzuraten, aber wenn es gar nicht funktioniert, dann sollte es aus dem FHEM Verzeichnis entfernt werden.

Ok. Wie gesagt - es lädt nicht, weil es ein OW.pm nicht finden kann. Ich kann's auch nicht finden, habe aber noch nicht "semantisch recherchiert".

zusätzlich zu dem oben gesagten sehe ich noch:

etliche "Prototype mismatch" Meldungen. Die würde man in FHEM nicht sehen, weil dort die Prototypen noch sind und es fällt nicht auf wenn ein Prototyp zweimal gleich definiert wird. Und genau deswegen ist das ein Problem, zeigt es doch Duplikate:
(Achtung, die Zeilennummern stimmen so nicht)


2020.06.03 13:08:52 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/00_OWX.pm line 52.
2020.06.03 13:08:53 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/00_OWX_ASYNC.pm line 94.
2020.06.03 13:08:53 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at FHEM/Color.pm line 11.
2020.06.03 13:08:53 1: PERL WARNING: sort (...) interpreted as function at ./FHEM/10_CUL_HM.pm line 5385.

2020.06.03 13:08:54 1: reload: Error:Modul 20_OWFS deactivated:
 Can't locate OW.pm in @INC (you may need to install the OW module)
=> gleiches Problem wie bei OWTEMP

2020.06.03 13:08:54 1: PERL WARNING: "my" variable $list masks earlier declaration in same scope at ./FHEM/21_N4HMODULE.pm line 1468.
2020.06.03 13:08:55 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWAD.pm line 49.
2020.06.03 13:08:56 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWCOUNT.pm line 48.
2020.06.03 13:08:56 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWID.pm line 50.
2020.06.03 13:08:57 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWLCD.pm line 79.


2020.06.03 13:08:58 1: reload: Error:Modul 21_OWSWITCH deactivated:
 syntax error at ./FHEM/21_OWSWITCH.pm line 1869, near "= ;"
syntax error at ./FHEM/21_OWSWITCH.pm line 1892, near "= ;"


2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWTHERM.pm line 46.
2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::AttrVal: none vs ($$$) at ./FHEM/21_OWTHERM.pm line 47.

2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_OWVAR.pm line 47.
2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::AttrVal: none vs ($$$) at ./FHEM/21_OWVAR.pm line 48.

2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/21_SONOSPLAYER.pm line 58.
2020.06.03 13:08:58 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/30_tradfri.pm line 29.
2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/33_readingsGroup.pm line 32.
2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/33_readingsHistory.pm line 31.
2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/33_readingsProxy.pm line 33.

2020.06.03 13:08:59 1: PERL WARNING: Smartmatch is experimental at ./FHEM/36_EleroDrive.pm line 271.
2020.06.03 13:08:59 1: PERL WARNING: Smartmatch is experimental at ./FHEM/36_EleroSwitch.pm line 225.

2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/39_alexa.pm line 25, <DATA> line 1.
2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/39_gassistant.pm line 24.
2020.06.03 13:08:59 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/39_siri.pm line 14.

2020.06.03 13:08:59 1: PERL WARNING: Smartmatch is experimental at ./FHEM/45_Plugwise.pm line 949.

2020.06.03 13:08:59 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 605.
2020.06.03 13:08:59 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 1140.

2020.06.03 13:08:59 1: PERL WARNING: %defptr{...} in scalar context better written as $defptr{...} at ./FHEM/49_Arlo.pm line 916.

2020.06.03 13:09:00 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/98_dewpoint.pm line 32.

2020.06.03 13:09:00 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 307.
2020.06.03 13:09:00 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 335.
2020.06.03 13:09:00 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 452.

2020.06.03 13:09:00 1: PERL WARNING: Smartmatch is experimental at ./FHEM/56_POKEYS.pm line 324

2020.06.03 13:09:00 1: reload: Error:Modul 59_OPENWEATHER deactivated:
 Unrecognized character \xC3; marked by <-- HERE after <-- HERE near column 1 at ./FHEM/59_OPENWEATHER.pm line 1.

2020.06.03 13:09:00 1: PERL WARNING: Subroutine getIP redefined at ./FHEM/70_SamsungAV.pm line 1445.
2020.06.03 13:09:00 1: PERL WARNING: Subroutine getIP_old redefined at ./FHEM/70_SamsungAV.pm line 1453.
2020.06.03 13:09:00 1: PERL WARNING: Subroutine getMAC4IP redefined at ./FHEM/70_SamsungAV.pm line 1463.

2020.06.03 13:09:01 1: PERL WARNING: Smartmatch is experimental at ./FHEM/71_YAMAHA_MC.pm line 6215.
2020.06.03 13:09:01 1: PERL WARNING: Smartmatch is experimental at ./FHEM/71_YAMAHA_MC.pm line 6456

2020.06.03 13:09:01 1: PERL WARNING: Prototype mismatch: sub main::Log3: none vs ($$$) at ./FHEM/74_UnifiVideo.pm line 18.

2020.06.03 13:09:01 1: PERL WARNING: Smartmatch is experimental at ./FHEM/77_SMASTP.pm line 200.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 93.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 102.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 113.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 117.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 120.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 123.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 127.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 129.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/77_SMASTP.pm line 131.
2020.06.03 13:09:01 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/77_SMASTP.pm line 133.

2020.06.03 13:09:01 1: reload: Error:Modul 88_HMCCURPC deactivated:
 Attempt to reload threads.pm aborted.
Compilation failed in require at ./FHEM/88_HMCCURPC.pm line 28.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCURPC.pm line 28.

2020.06.03 13:09:01 1: PERL WARNING: Useless use of private variable in void context at ./FHEM/93_DbLog.pm line 865.

2020.06.03 13:09:02 1: PERL WARNING: Scalar value @args[0] better written as $args[0] at ./FHEM/95_PostMe.pm line 1093.
2020.06.03 13:09:02 1: PERL WARNING: Scalar value @args[0] better written as $args[0] at ./FHEM/95_PostMe.pm line 1173.

2020.06.03 13:09:02 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 1273.
2020.06.03 13:09:02 1: PERL WARNING: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 2557.

2020.06.03 13:09:02 1: PERL WARNING: main::Snapcast_setClient() called too early to check prototype at ./FHEM/96_Snapcast.pm line 635.

Die anderen - teils fatalen - Fehler will ich erstmal checken ob das nicht HoBo-spezifisch ist.

24_SI_Liquid_Check.pm ist nicht Teil vom FHEM SVN, kann man also hier erstmal ignorieren.

2020.06.03 13:08:58 1: PERL WARNING: Scalar value @adays[...] better written as $adays[...] at ./FHEM/24_SI_Liquid_Check.pm line 368.
2020.06.03 13:08:58 1: PERL WARNING: Scalar value @amonth[...] better written as $amonth[...] at ./FHEM/24_SI_Liquid_Check.pm line 368.
2020.06.03 13:08:58 1: PERL WARNING: Scalar value @adays[...] better written as $adays[...] at ./FHEM/24_SI_Liquid_Check.pm line 373.
2020.06.03 13:08:58 1: PERL WARNING: Scalar value @amonth[...] better written as $amonth[...] at ./FHEM/24_SI_Liquid_Check.pm line 373.
Titel: Antw:Unit Test?
Beitrag von: zap am 03 Juni 2020, 19:27:45
Ich versuche, 88_HMCCURPC.pm aus dem SVN zu löschen. Mal sehen, ob ich das darf.
Jedenfalls ist das Modul obsolet und wurde durch 88_HMCCURPCPROC.pm ersetzt.
Titel: Antw:Unit Test?
Beitrag von: Wzut am 03 Juni 2020, 20:02:58
Ok. Wie gesagt - es lädt nicht, weil es ein OW.pm nicht finden kann. Ich kann's auch nicht finden, habe aber noch nicht "semantisch recherchiert".
du bist nicht der erste der das sucht -> https://forum.fhem.de/index.php?topic=39129.0
war wohl 2015 Betandteil irgend eines owfs Packets, vllt sollte man diese ganzen OW Leichen einfach löschen oder zumindest nach contrib verschieben,
Norbert (ntruchsess) ist doch eh schon jahrelang nicht mehr aktiv
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 03 Juni 2020, 20:59:36
Zitat
vllt sollte man diese ganzen OW Leichen einfach löschen
Gerne, aber das soll bitte jemand machen, der weiss, was alles dazugehoert.
Titel: Antw:Unit Test?
Beitrag von: Ralf9 am 04 Juni 2020, 00:40:40
Anderweitiges Durchwühlen brachte:

2020.06.02 19:37:13 0: Bareword "NULL" not allowed while "strict subs" in use at ./FHEM/00_SIGNALduino.pm line 4982.

->

            my $osv2byte = "";
            $osv2byte = NULL;
            $osv2byte = substr( $bitData, $idx, 16 );

Hallo,

ich habe mir einen fork vom Signalduino Modul erstellt und diesen für meine Bedürfnisse angepasst und erweitert.
Im Gegensatz von einigen hier, die berufsmäßig programmieren, mache ich das programmieren Hobbymäßig, ich habe es mir aus dem Internet selbst beigebracht.
So wie einige professionelle Programmierer hier Ihre Module umgeschrieben und optimiert haben, habe ich mit meinen Kenntnissen probleme die Funktionsweise zu verstehen.
Sidey, z.B. ist gerade dabei das 00_SIGNALduino zu optimieren und umzuschreiben.
Die Optimierungen und der Code für die Unit Tests sind mittlerweile so umfangreich, daß ich nicht mehr in der Lage bin den kompletten Code nachzuvollziehen und zu verstehen.
Der Aufwand der für Unit Tests gemacht wird ist mir zu heftig, ich teste lieber auf herkömmliche Weise.

Wenn ich fragen zum Verbessern und Optimieren meines geforkten 00_SIGNALduino Moduls habe, darf ich hier in der Perlecke auch fragen, wenn ich kein maintainer bin?
Falls ja, in welches Thema passt dies am Besten oder soll ich hier ein neues Thema aufmachen?   

Gruß Ralf
Titel: Antw:Unit Test?
Beitrag von: Sidey am 04 Juni 2020, 08:05:28



2020.06.02 19:37:13 0: Bareword "NULL" not allowed while "strict subs" in use at ./FHEM/00_SIGNALduino.pm line 4982.

Das kann doch noch nie funktioniert haben - oder?

Ich glaube auch, das hat nie den Effekt gebracht den (vermutlich ich) mir damals erhofft hatte.

Dieser und viele andere Fehler sind auch schon im development Branch behoben:


https://github.com/RFD-FHEM/RFFHEM/blob/dev-r35_xFSK/FHEM/lib/SD_Protocols.pm

Klingt jetzt komisch, aber auf Basis vom Master macht es derzeit keinen Sinn patches oder PRs zu eröffnen, da bereits vieles im development Branch umgebaut wurde.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 04 Juni 2020, 09:00:11
Klingt jetzt komisch, aber auf Basis vom Master macht es derzeit keinen Sinn patches oder PRs zu eröffnen, da bereits vieles im development Branch umgebaut wurde.

Ist schon ok, aber dann vielleicht zügig an dev -> master planen. Nur so fällt der neue Code in die CI Mühle.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 04 Juni 2020, 09:47:19
Wenn ich fragen zum Verbessern und Optimieren meines geforkten 00_SIGNALduino Moduls habe, darf ich hier in der Perlecke auch fragen, wenn ich kein maintainer bin?

Selbstverständlich. Was mich betrifft, so ist das FHEM Entwicklungsmodell mit den heiligen Maintainern eh kaputt.
(und weil wegen der Aussage vmtl. wieder irgendjemand auf die Barrikaden steigt: Ich bin wenigstens hier um diese Meinung kundzutun! Alle Kollegen schnauben bislang nur verächtlich und melden sich nichtmal im Forum an, verstehen auch nicht was ich an FHEM sehe.)

Hinsichtlich Unit-Tests, umfangreich, nicht nachvollziehbar... Nuja: das Ziel ist eigentlich den Code sauberer (= übersichtlicher) und robuster zu machen.
Es gibt noch praktisch keinen Code für Unit-Tests, verstehe nicht was da umfangreich sein soll. Und das wenige was es gibt, fördert bereits Schnitzer zu Tage.

Aber wie gesagt: wenn Fragen sind, jederzeit. Mach einfach einen Thread "Code Review: 00_SIGNALduino" und kipp dort rein was Du wissen willst.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 04 Juni 2020, 10:02:19
2020.06.04 09:53:38 1: reload: Error:Modul 98_configdb deactivated:
 Bareword "_cfgDB_Connect" not allowed while "strict subs" in use at configDB.pm line 263.
Bareword "_cfgDB_Uuid" not allowed while "strict subs" in use at configDB.pm line 286.
Compilation failed in require at ./FHEM/98_configdb.pm line 9.
BEGIN failed--compilation aborted at ./FHEM/98_configdb.pm line 9.

Ne, das liegt nicht an HoBo. Das liegt daran, dass man Prototypen mag, diese falsch verwendet und überdies nicht weiß wie man Funktionsaufrufe zu gestalten hat.
Da ich aber ansonsten Abstraktionsfähigkeit voraussetze, reicht ein Beispiel:

my $fhem_dbh = _cfgDB_Connect;
->
my $fhem_dbh = _cfgDB_Connect();

Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 04 Juni 2020, 11:00:26
https://gl.petatech.eu/root/HomeBot/-/jobs/180

23 Tests fliegen mir noch um die Ohren - einiges davon ist zweifelsohne HoBo-spezifisch (lies: RichardCZ macht auch Bugs), andere Sachen nicht.
Ich kehre jetzt erstmal vor der eigenen Haustür.

edit:

got: 'syntax error at ./FHEM/21_SONOSPLAYER.pm line 219, near "SONOS_Log undef"
kann man leicht abstellen: SONOS_Log -> SONOSPLAYER_Log
Titel: Antw:Unit Test?
Beitrag von: zap am 04 Juni 2020, 11:06:36
88_HMCCURPC.pm wurde aus dem Repository entfernt.

Titel: Antw:Unit Test?
Beitrag von: Sidey am 04 Juni 2020, 22:27:21
Ist schon ok, aber dann vielleicht zügig an dev -> master planen. Nur so fällt der neue Code in die CI Mühle.

Ist diese "CI Mühle" in FHEM integriert oder kann ich das integrieren? Ich hab schon einen automatisierten Testprozess der auch Problemlos in meinen feature branches nach jedem commit läuft.
Titel: Antw:Unit Test?
Beitrag von: RichardCZ am 05 Juni 2020, 08:42:52
Ist diese "CI Mühle" in FHEM integriert oder kann ich das integrieren? Ich hab schon einen automatisierten Testprozess der auch Problemlos in meinen feature branches nach jedem commit läuft.

Mit "CI Mühle" meine ich die GitLab CI Pipeline (siehe z.B.  https://gl.petatech.eu/root/HomeBot/pipelines/118), die seit gestern bei mir auch erfolgreich statische Binaries baut (aber noch nicht abholt - artifact download und dann irgendwo auf dem Web als "release" bereitstellt - kommt noch).

Wie man bei dem klick auf "perl prove" sehen kann gibt's derzeit 160+ Unit-Tests und knapp 560 basale Funktionstests (*) die auch durchlaufen.

Hier https://gl.petatech.eu/root/HomeBot/-/commit/fca05393b181599746ea12694b4e9fdffc9d7deb
sind die ~20 Module, denen ich erstmal besagtes Morphiumpflaster verpasst habe, weil sie nichtmal erfolgreich laden. (würde mich freuen, wenn nicht nur ich mich da durchpflügen müsste)

Wenn Du mir einen Link auf Deinen automatisierten Testprozess schicken könntest, kann ich ja schauen ob/wie ich den integrieren kann.


(*) Und ich möchte betonen, dass diese dank Rudolf da sind, weil er "mal eben" zeigen konnte wie man die machen kann. Wenn man sich den Anfang des Threads anschaut, dann sieht man, dass ich erstmal nicht gewusst hätte wie. (https://forum.fhem.de/index.php/topic,111061.msg1060028.html#msg1060028 - da habe ich noch Stoff für einiges was ich tun kann)



Ich hoffe ja, dass "man hierzulande" den Nutzen dieser Tests sieht und Interesse, Ideen für Weiteres in dieser Richtung aufbringt. Alleine diese grundlegenden "laden wir einfach mal das Modul" Tests haben schon eine Menge Erkenntnisgewinn (und Bugs) offenbart:

Und das alles ist eine gute Sache! Der Punkt der Tests ist ja nicht primär zu zeigen in welchem furchtbaren Zustand die FHEM Codebasis ist.
Ich finde, da gehen bei vielen viel zu schnell die Schotten dicht. Der Punkt ist doch eigentlich dank dieser Tests Probleme zu beheben und zwar
(diese Probleme) für immer, weil die Tests ja nicht weggehen. Wer nicht sieht, dass dadurch der Code kategorisch besser wird: ¯\_(ツ)_/¯
Titel: Antw:Unit Test?
Beitrag von: Sidey am 06 Juni 2020, 01:30:53
Wenn Du mir einen Link auf Deinen automatisierten Testprozess schicken könntest, kann ich ja schauen ob/wie ich den integrieren kann.


Ich hatte gedacht, dass ich vielleicht etwas allgemeingültiges integrieren könnte. Daher auch die Frage, ob die Tests schon in FHEM integriert sind.

Ich deploye nichts, daher auch keine pipeline. Wäre aber mal eine Idee, ob ich nicht ins SVN deployen könnte. hmmmmm  8)
https://github.com/RFD-FHEM/RFFHEM/actions/runs/125311624
Titel: Antw:Unit Test?
Beitrag von: StefanStrobel am 23 August 2020, 20:42:04
Hallo Rudi,

könntest Du die FhemTestUtils um eine Funktion erweitern, die die Zeit einer im Log gefundenen Zeile liefert?
z.B.:
sub FhemTestUtils_getLogTime {
    my $arg = shift;
    foreach my $line (@logs) {
        if ($line =~ m{ \A ([0-9\.]+ \s [0-9\:\.]+) \s .* $arg .* }xms) {
            my @a = split("[T: -\.]", $1);
            return mktime($a[5],$a[4],$a[3],$a[2],$a[1]-1,$a[0]-1900,0,0,-1) + $a[6]/1000;
        }
    }
    return;
}

Ich habe so für Modbus die Möglichkeit die Timing-Parameter zu testen.

Gruss / Thanx
    Stefan
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 24 August 2020, 12:24:46
Danke fuer den Patch, habs hinzugefuegt und dokumentiert.
Ich musste es etwas anpassen, u.a. weil mseclog nicht immer aktiviert ist: kannst Du es bitte testen.

Apropos Unit-Test:
- die HTTPMOD Tests benoetigen die JSON und Test::V0 perl Module.  Ich wuensche mir, dass das Fehlen von optionalen perl Modulen kein Fehler, sondern eine Bemerkung beim Test produziert, so wie bei etlichen Perl-Modulen.
- selbst nach Installieren des JSON Moduls bleiben 3 HTTPMOD Fehler uebrig.
Titel: Antw:Unit Test?
Beitrag von: StefanStrobel am 25 August 2020, 16:52:34
Danke fuer den Patch, habs hinzugefuegt und dokumentiert.
Ich musste es etwas anpassen, u.a. weil mseclog nicht immer aktiviert ist: kannst Du es bitte testen.
funktioniert. Vielen Dank!

Zitat
Apropos Unit-Test:
- die HTTPMOD Tests benoetigen die JSON und Test::V0 perl Module.  Ich wuensche mir, dass das Fehlen von optionalen perl Modulen kein Fehler, sondern eine Bemerkung beim Test produziert, so wie bei etlichen Perl-Modulen.
- selbst nach Installieren des JSON Moduls bleiben 3 HTTPMOD Fehler uebrig.

Das ist ein guter Punkt. Wenn ein Test JSON-Features von HTTPMOD testet, dann schlagen die natürlich fehl, wenn die dafür nötigen Libs nicht vorhanden sind.
Ich würde das so umbauen, dass diese Tests nur noch ausgeführt werden wenn die Libs auch da sind und andernfalls eine Meldung erzeugen.

Was wäre denn der bevorzugte Melde-Weg? Log3 oder gibt es da etwas Test-spezifisches?

Die offenen Fehler sind übrigens echte Bugs, die in der nächsten HTTPMOD-Version behoben sind (gerade im Forum mit der Bitte um Tests von Anwendern)

Gruß
    Stefan
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 25 August 2020, 17:42:52
Zitat
Was wäre denn der bevorzugte Melde-Weg? Log3 oder gibt es da etwas Test-spezifisches?
Was Test-spezifisches, was man beim ausfuehren von prove sieht.
Wie das geht, muesste ich auch erforschen.
Titel: Antw:Unit Test?
Beitrag von: Sidey am 25 August 2020, 18:38:30
Da gibt es was von der Stange um auf Packages zu prüfen:

https://metacpan.org/pod/Test2::Require::Module

Grüße Sidey
Titel: Antw:Unit Test?
Beitrag von: StefanStrobel am 28 August 2020, 19:44:38
Hallo,

ich habs jetzt so gelöst:
##############################################
# test extractAllReadings
##############################################
use strict;
use warnings;
use Test::More;

eval "use JSON";
if ($@) {
    plan skip_all => "This test checks an optional JSON-Feature of HTTPMOD and can only be run with the JSON library installed. Please install JSON Library (apt-get install libjson-perl)";
} else {
    plan tests => 3;
}
...

benötigt kein Test2 und zeigt bei prove eine nette Meldung an:
pi@PI-Fhem:/opt/fhem $ prove `find t/FHEM/98_HTTPMOD -name \*.t`
t/FHEM/98_HTTPMOD/40_maxAge.t .......... ok
t/FHEM/98_HTTPMOD/99_evalExpr.t ........ ok
t/FHEM/98_HTTPMOD/50_Replacements.t .... ok
t/FHEM/98_HTTPMOD/20_extractAllJSON.t .. skipped: This test checks an optional JSON-Feature of HTTPMOD and can only be run with the JSON library installed. Please install JSON Library (apt-get install libjson-perl)
t/FHEM/98_HTTPMOD/90_SmallFeatures.t ... ok
t/FHEM/98_HTTPMOD/30_requestExpr.t ..... ok
t/FHEM/98_HTTPMOD/31_Regexes.t ......... ok
t/FHEM/98_HTTPMOD/10_Redirects.t ....... ok
t/FHEM/98_HTTPMOD/36_JSONExpr.t ........ skipped: This test checks an optional JSON-Feature of HTTPMOD and can only be run with the JSON library installed. Please install JSON Library (apt-get install libjson-perl)
All tests successful.
Files=9, Tests=39,  9 wallclock secs ( 0.28 usr  0.00 sys +  7.25 cusr  0.34 csys =  7.87 CPU)
Result: PASS

Um in einem Test erst mal zu prüfen, ob ein Modul da ist mache ich das mit:
use_ok ('FHEM::HTTPMOD::Utils', qw(:all));

auch das geht mit Test::More. Test2 habe ich gar nicht verwendet, da das ja auch wieder fehlen könnte.

Gruss
   Stefan
Titel: Antw:Unit Test?
Beitrag von: Sidey am 28 August 2020, 20:04:14
Geht natürlich auch so mit eval, meine 5ct:
Verwende gleich Test2 wenn Du noch am Anfang stehst, das bringt viele Vereinfachungen mit und wird weiter entwickelt.

Gruß Sidey
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 28 August 2020, 20:35:07
@Stefan: Danke!
Titel: Antw:Unit Test?
Beitrag von: StefanStrobel am 27 November 2020, 15:34:50
Hallo Rudi,

würde etwas dagegen sprechen in DevIo die Zeile
use Time::HiRes     qw(time);
oben einzufügen?
Dann könnte man auch Bruchteile von Sekunden für nextOpenDelay verwenden.

Ich versuche gerade weitere Tests für das Modbus-Modul zu schreiben, unter anderem für das Timing. Da wäre es hilfreich, wenn man auch kurze Delays setzen könnte, die dann auch exakt umgesetzt werden. Bei der aktuellen Auflösung auf die jeweils nächste volle Sekunde, müssten die Tests jeweils mehrere Sekunden laufen.
Außer der obigen Zeile wären keine weiteren Änderungen nötig.

Gruss
   Stefan
Titel: Antw:Unit Test?
Beitrag von: rudolfkoenig am 27 November 2020, 17:27:23
Ich habe lieber time() durch gettimeofday() ersetzt.
Sie wird bereits in fhem.pl reingeholt, ich verwende sie eher, und weiss deswegen sofort, dass hier irgendwas mit Nachkommastellen gemacht wird.
Titel: Antw:Unit Test?
Beitrag von: StefanStrobel am 27 November 2020, 19:36:29
Vielen Dank!

Gruss
   Stefan