Hauptmenü

Unit Test?

Begonnen von herrmannj, 10 Mai 2020, 12:54:23

Vorheriges Thema - Nächstes Thema

rudolfkoenig

#30
ZitatGibt 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.

ZitatIch 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

ZitatAlso ich sehe nicht mehr als die eine Umbenennung.
Na dann: umbenannt.

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

CoolTux

Zitat von: Sidey am 14 Mai 2020, 08:43:26
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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RichardCZ

Zitat von: rudolfkoenig am 13 Mai 2020, 23:55:56
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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

justme1968

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 ?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

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

Zitatein 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.

Zitatwie 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.

Zitatwie 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.


Zitatwenn man für den -t <param> aufruf aus versehen ein directory als parameter angibt beendet sich das ganze nicht.
Habe Pruefung & Beenden eingebaut

RichardCZ

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($);
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Sidey



Zitat 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:

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

Ich verstehe die Frage nicht, und rate: hast Du exit(0) zu frueh ausgefuehrt?
Mein Test funktioniert, habs gerade kontrolliert.

Sidey

Zitat 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.

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. :)
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

betateilchen

Zitat von: Sidey am 16 Mai 2020, 21:50:58
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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

RichardCZ

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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.