Unit Test?

[herrmannj]

Wie würde man denn entsprechende Unit Tests organisieren können? Hat da jemand Ideen und Erfahrungen?

[Sidey]

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

[herrmannj]

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 (?)

[RichardCZ]

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.

[herrmannj]

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

[Sidey]

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

[RichardCZ]

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.

[herrmannj]

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.

[RichardCZ]

 

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?

[rudolfkoenig]

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.

[Sidey]

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

[RichardCZ]

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.

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:

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.

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.

[herrmannj]

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

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.

[herrmannj]

 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?

[RichardCZ]

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.