Unit Test?

[rudolfkoenig]

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.

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

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

[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

[CoolTux]

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.

[RichardCZ]

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.

[justme1968]

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

# 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 ?

[rudolfkoenig]

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

Habs eingecheckt.

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.

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.

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.

wenn 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($);

[Sidey]

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

[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

[rudolfkoenig]

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

[Sidey]

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.

[betateilchen]

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.

[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

[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

Code: [Auswählen]

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:

Code: [Auswählen]

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.