TestSuite für automatisierte Tests

[Brovning]

Discussed in https://github.com/elueckel/Unifi-Toolbox/discussions/36

^{Originally posted by **Brovning** January 3, 2022} Ähnlich der Action für den CodeStyle-Check kann bei jedem Checkin auch automatisch eine TestSuite als Action ausgeführt werden, um die grundlegende Funktionalität automatisch zu testen und sicherzustellen (siehe: https://youtu.be/kTcuTO50Jzw). Für jeden gemeldeten Fehler sollte dann zukünftig auch ein Testfall zum abtesten erstellt werden. Das Problem, was ich aktuell sehe, dass man einen curl-Stub selbst erstellen müsste...

[Brovning]

https://github.com/elueckel/Unifi-Toolbox/tree/TestSuite

[Brovning]

@elueckel Nachdem ich mich jetzt fast 30h mit dem Thema TestSuite beschäftigt habe, kann ich behaupten, dass ich demnächst mit dem ersten Schuss fertig sein werde.

Nach der Umstellung auf den zentralen Konfigurator sollte die TestSuite nach wie vor durchlaufen (lediglich die Tests mit Serveradresse, Port, User und Passwort müssten angepasst werden) und uns die grundlegenden Fehler zeigen.

Man war das ein Sch...

[Brovning]

erster erfolgreicher Testlauf: https://github.com/elueckel/Unifi-Toolbox/actions/runs/1670728737

[Brovning]

TestSuite successfully merged to beta:

[Brovning]

@elueckel : mach mal bitte ein Update bei dir im IPS, ob das Update durchläuft. Bei mir gab es Probleme, vermute jedoch, dass es damit zu tun hatte, dass ich hin und her geändert hatte...

[Brovning]

Habe auch das Fehlerhandling und die Fehlerausgaben überarbeitet, um dem User bessere Hilfestellungen zu geben:

[elueckel]

Update auf die Testsuite hat bei mir ohne Probleme geklappt. Das mit den Fehlermeldungen geht auch - sehr cooles Feature. Ich will am Wochenende noch ein Modul für meinen Charger bauen, da es nächste Woche wieder weniger Zeit gibt. Evtl. komme ich am Mittwoch dazu mal den WLAN Controller zu bauen. Am 2022-01-08 18:04, Brovning @.> schrieb: > > > Habe auch das Fehlerhandling und die Fehlerausgaben überarbeitet, um dem User bessere Hilfestellungen zu geben: > > > > > > > > > — > Reply to this email directly, view it on GitHub (https://github.com/elueckel/Unifi-Toolbox/issues/53#issuecomment-1008064658), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AHI57O5QCDSRGV5OH75ZX7LUVBU75ANCNFSM5LKALE2Q). > You are receiving this because you were mentioned.Message ID: @.> > >

[Brovning]

@elueckel Zur Verwendung der TestSuite: Wenn du in den Ordner tests wechselst, kannst du vor Checkin einer Änderung per Klick auf "Run" die Tests des jeweiligen Moduls ausführen lassen:

Des Weiteren werden die Tests immer automatisch nach jedem Checkin ausgeführt und man wird bei einem Fehler per Mail benachrichtigt.

Die TestSuite ist jetzt lediglich als Basis zu verstehen und müsste noch deutlich erweitert werden, um die Gesamtfunktionalität abzutesten.

[elueckel]

Hi @Brovning, sorry das ich mich erst jetzt melde ... ich schaue mal das ich mir das Testing die Tage anschaue - sieht ziemlich cool aus! Wie funktioniert das mit den Tests - was wird denn im Detail getestet in den Modulen?

[Brovning]

Hallo @elueckel ,

Ich habe versucht je Testcase einen Kommentar hinzuzufügen mit:

• Was wird geändert/gemacht?
• Was wird abgetestet und erwartet?

Jedes Modul hat seine eigene Testdatei.

[Brovning]

Tests für ControllerType=1 hinzugefügt.

Ein Modul Status ist für ControllerType=1 jedoch anders als erwartet. Verwendet man bei einem ControllerType=1 (vorhandener Controller) im Modul die falsche Konfiguration für ControllerType=0 (müsste eigentlich 1 sein!), dann wird der ModulStatus auf 201, anstatt 200 gesetzt... --> siehe TestCase 22 (action: set wrong ControllerType)

// expected module status code: $this->assertEquals(200, IPS_GetInstance($myModuleId)['InstanceStatus'], "TC".$tdId.": Module GetStatus() return value");
$this->assertEquals(201, IPS_GetInstance($myModuleId)['InstanceStatus'], "TC".$tdId.": Module GetStatus() return value");

Jetzt ist die Frage, ob es ein Fehler im UnifiControllerStub ist oder der ModulStatus bei ControllerType=1 in diesem Fall korrekt ist...

Komischerweise ist das nur der Fall bei:

• Device Monitor
• Endpoint Blocker
• Endpoint Monitor

Aber nicht bei:

• Presence Manager

Wenn du das herausbekommen würdest... :-) Ich gebe soeben auf.

[elueckel]

Isch gucke morgen mal …

Am 25.01.2022 um 21:18 schrieb Brovning @.***>:

 Tests für ControllerType=1 hinzugefügt.

Ein Modul Status ist für ControllerType=1 jedoch anders als erwartet. Verwendet man bei einem ControllerType=1 (vorhandener Controller) im Modul die falsche Konfiguration für ControllerType=0 (müsste eigentlich 1 sein!), dann wird der ModulStatus auf 201, anstatt 200 gesetzt...

Jetzt ist die Frage, ob es ein Fehler im UnifiControllerStub ist oder der ModulStatus bei ControllerType=1 in diesem Fall korrekt ist...

Komischerweise ist das nur der Fall bei:

Device Monitor Endpoint Blocker Endpoint Monitor Aber nicht bei:

Presence Manager Wenn du das herausbekommen würdest... :-) Ich gebe soeben auf.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[Brovning]

Danke!

Vielleicht müsste man mal einen CloudKey/selbstgehosteten Controller (=ControllerType 1) nehmen und mit der Configuration für DreamMachine (ControllerType=0) testen, was hier der Modulstatus ist. Ist der ebenfalls 201, dann passt es. Wenn er jedoch 200 ist, geht es ans Debuggen und vergleichen der Rückgabewerte von Controller und ControllerStub...

[elueckel]

Ich habe das nochmal überflogen und kann hier nichts sehen.

Einen seperaten Controller mit DM kann ich nicht aufsetzen. Wenn das Internet weg ist oder nur das geringste Problem, dann läuft die Familie amok … bei mir läuft alles ohne Probleme und fehler.

Am 26.01.2022 um 08:07 schrieb Brovning @.***>:

Danke!

Vielleicht müsste man mal einen CloudKey/selbstgehosteten Controller (=ControllerType 1) nehmen und mit der Configuration für DreamMachine (ControllerType=0) testen, was hier der Modulstatus ist. Ist der ebenfalls 201, dann passt es. Wenn er jedoch 200 ist, geht es ans Debuggen und vergleichen der Rückgabewerte von Controller und ControllerStub...

— Reply to this email directly, view it on GitHub https://github.com/elueckel/Unifi-Toolbox/issues/53#issuecomment-1021924224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHI57O6XUKGWJNVVVHO2R7LUX6MTPANCNFSM5LKALE2Q. You are receiving this because you were mentioned.

[Brovning]

Habe einen Controller aufgesetzt und getestet. Beim Controller erhält man 401 (=ModulStatus 201) und bei einer UDM erhält man 404 (=ModulStatus 200), wenn man den falschen ControllerTyp einstellt.

Und jetzt die Frage aller fragen: Warum kommt dann beim Presence Manager mit einem selbst gehosteten Controller ein anderer Modul-Status als bei den anderen...

[elueckel]

Ich habe heute mal wieder ins Modul geschaut und den Fehler von Stefan mit der Satisfaction gefixed (war ja auch einer der Bugs).

Ich bekomme jetzt aber das Modul nicht mehr in der Store - scheint am Testing zu hängen? Hast du da eine Idee ... ich muss zugeben, dass das Testing etwas über meinem Skilllevel liegt - vor allem weil ich auch nur alle Schaltjahre Code.

[Brovning]

Hallo,

hm... der konnte aus Git nicht auschecken:

Checke nochmals eine Änderung ein. Läuft er dann durch?

EDIT: Musst nichts mehr einchecken. Denke den Fehler verstanden zu haben. Schaue ich mir voraussichtlich Morgen an. Bin aktuell im Urlaub...

[Brovning]

So, habe die IP-Symcon Stubs aktualisiert. Jetzt läuft die TestSuite wieder und wirft folgende Fehlermeldung:

Grund ist folgende Code-Änderung in den Stubs: https://github.com/symcon/SymconStubs/pull/57/files

Soweit ich das verstehe, wird nun getTime() im Module under Test benötigt...

[elueckel]

Hmmm … also irgendwie macht diese Test Suite das Ganze komplizierter und liefert übersichtlich viel Mehrwert.

Wo müsste dann getTime hin kommen … die aktuelle Zeit braucht das Modul ja garnicht zum setzen des Timers, da der Timer ja zyklisch läuft?

Hast du da eine Idee? Sonst würde ich den Test-Teil raus nehmen - so richtig Mehrwert liefert er ja nicht (ausser das er dich für lange Zeit für den Einbau beschäftigt hat :-) ).

Was denkst du?

Am 04.10.2022 um 15:42 schrieb Brovning @.***>:

So, habe die IP-Symcon Stubs aktualisiert. Jetzt läuft die TestSuite wieder und wirft folgende Fehlermeldung: https://user-images.githubusercontent.com/39644775/193834495-e689218b-2ab5-4d01-8ec1-ed5bbd28c2be.png Grund ist folgende Code-Änderung in den Stubs: https://github.com/symcon/SymconStubs/pull/57/files https://github.com/symcon/SymconStubs/pull/57/files Soweit ich das verstehe, wird nun getTime() im Module under Test benötigt...

— Reply to this email directly, view it on GitHub https://github.com/elueckel/Unifi-Toolbox/issues/53#issuecomment-1267021457, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHI57OZMDI5GJ5KKK4TETQDWBQX27ANCNFSM5LKALE2Q. You are receiving this because you were mentioned.

[Brovning]

Ich habe bei Nils (hat diese Exception implementiert) angefragt, wo das getTime hin muss. Hoffe ich bekomme Rückmeldung. Würde das dann entsprechend ergänzen.

Bei den Stubs von IP-Symcon finde ich schwach, dass es Quasi keinerlei Doku gibt. Was wäre denn dabei zu schreiben, was bei welchem Fehler schief läuft bzw. gemacht werden muss...

[Brovning]

Richtig viel bringen würde die TestSuite bei größeren Änderungen. Ich denke hier an die zentrale Konfigurator-Instanz. ;-)

[elueckel]

Das kann sein, aber ich werde dasModul nicht umbauen - danach kann es auch nicht mehr 😁. Ich schaue mir evtl nochmal das mit dem wlan an - das Problem ist aktuell die Zeit.Am 04.10.2022 um 18:49 schrieb Brovning @.***>: Richtig viel bringen würde die TestSuite bei größeren Änderungen. Ich denke hier an die zentrale Konfigurator-Instanz. ;-)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[Brovning]

Habe mal den Testaufruf deaktiviert, bis ich weis, wo man das "getTime" einbauen muss...

[Brovning]

Niels hat geantwortet. --> Problem behoben. Tests wieder aktiviert.