Wie Übergangshaken mit ui-Router 1.0.x getestet werden

9

Ich migriere auf die neueste stabile Version von ui-router und verwende die $ transitions-Lebenszyklus-Hooks, um bestimmte Logik auszuführen, wenn bestimmte Zustandsnamen in einen Übergang umgewandelt werden.

In einigen meiner Controller habe ich jetzt so etwas:

%Vor%

In meinem Unit-Test für den Controller würde ich zuvor ein Zustandsänderungsereignis auf dem $ rootScope mit den bestimmten Zustandsnamen übertragen, wenn das Ereignis die Bedingungen trifft, die ich testen muss.

z.B.

%Vor%

Da diese Statusereignisse veraltet sind, was ist nun der richtige Weg, um die $transitions.onStart(...) Hooks in den Tests auszulösen?

Ich habe versucht, in meinen Tests nur $state.go('some-state-name') aufzurufen, aber ich kann niemals meine eigene Logik innerhalb der Transition-Hook-Callback-Funktion treffen. Laut der Dokumentation hier sollte der Aufruf von state.go programmatisch einen Übergang auslösen, es sei denn, ich lese falsch ?

Hat es noch jemand geschafft, Einheitentests für Übergangshaken in ihren Controllern zu bekommen, die für den neuen ui-router 1.0.x arbeiten?

Vollständiges Beispiel meines Controller-Codes, der einen Übergangshaken verwendet:

%Vor%

Testspezifikation:

%Vor%

Mein Spion wird nie getroffen, wenn die Anwendung lokal ausgeführt wird, wird dieser Hook wie erwartet aufgerufen, also muss es etwas sein, das ich in meinen Tests falsch eingerichtet habe. Gibt es noch etwas, das ich brauche, um den Übergang im Test erfolgreich zu machen, da ich mich am onSuccess-Event beteilige?

Danke

AKTUALISIEREN

Ich habe dies im Router-Raum auf gitter angesprochen und einer der Repo-Mitarbeiter kam zu mir zurück und schlug vor, den Aufruf von $state.go('home') in meinen tatsächlich durchgeführten Tests zu überprüfen, indem ich in meiner Testspezifikation expect($state.current.name).toBe('home'); hinzufüge.

Dies gilt für mich in meinem Test, aber ich kann immer noch nicht den Aufruf meiner Funktion im Transition-Hook-Callback ausführen:

Ich bin mir nicht sicher, wie ich weitermachen soll, außer dass ich installiert habe Polyfill für die Legacy-Ereignisse $ stateChange, so dass ich meinen vorherigen Code verwenden kann, aber ich möchte dies lieber nicht tun und herausfinden, wie man $ Übergangshaken richtig testet.

UPDATE 2

Nach der Antwort von estus habe ich jetzt den $transitions Dienst ausgedrckt und auch meinen Transition-Hook-Handler in eine private benannte Funktion in meinem Controller umgestaltet:

%Vor%

Jetzt in meiner Testspezifikation habe ich:

%Vor%

Diese Erwartungen sind erfüllt, aber ich bin immer noch nicht in der Lage, meine innere Logik in meiner Callback-Funktion onTransitionsSuccess namens hook, die einen Aufruf von setOpenItemsForState

aufruft, zu treffen

Was mache ich hier falsch?

UPDATE 3

Danke nochmal an estu, ich habe vergessen, dass ich einfach meine genannte Transition-Hook-Funktion aufrufen kann, ist ein separater Test:

%Vor%

Und jetzt bekomme ich 100% Deckung:)

Hoffentlich wird dies eine gute Referenz für andere sein, die vielleicht Schwierigkeiten haben, herauszufinden, wie sie ihre eigenen Übergangshaken testen können.

    
mindparse 27.10.2017, 12:55
quelle

1 Antwort

2

Eine gute Komponententeststrategie für AngularJS-Routing besteht darin, einen Router vollständig zu stopfen. Der echte Router verhindert, dass Einheiten effizient getestet werden und stellt unnötige bewegliche Teile und unerwartetes Verhalten bereit. Da sich ngMock anders verhält als echte Anwendungen, können solche Tests auch nicht als geeignete Integrationstests betrachtet werden.

Alle verwendeten Router-Dienste sollten stubbed sein. $stateProvider stub sollte sein grundlegendes Verhalten widerspiegeln, d. h. es sollte sich selbst am state -Aufruf zurückgeben und sollte $state stub für $get ruf zurückgeben:

%Vor%

Eine testfreundliche Methode besteht darin, gebundene Methoden als Callbacks anstelle von anonymen Funktionen bereitzustellen:

%Vor%

Dann können Stub-Methoden einfach getestet werden, dass sie mit passenden Argumenten aufgerufen wurden:

%Vor%

Eine Callback-Funktion kann direkt getestet werden, indem sie mit erwarteten Argumenten aufgerufen wird. Dies bietet eine vollständige Abdeckung und lässt dennoch einen Platz für menschliche Fehler, so dass Komponententests mit Integrations / E2e-Tests mit einem echten Router gesichert werden sollten.

    
estus 12.11.2017, 19:00
quelle