Mocking von Vuex in Storybook und Vue Test Utils

tl;dr: Scrollen Sie sofort nach unten zur Schlussfolgerung

• In Storybook ist jede Geschichte eine neue Vue-App
  ⇒ Vuex-Plugin auf Vue-Prototyp registrieren
• In Vue Test Utils verwendet jeder Test den bestehenden Vue-Konstruktor
  ⇒ Vuex-Plugin auf lokaler Vue-Instanz registrieren

---

Dieser Blog-Beitrag zeigt, wie Sie einen einfachen Unit-Test und eine Story für eine Komponente einrichten, die mit einem Vuex-Store verbunden ist. Bei diesen Komponenten handelt es sich in der Regel um Smart/Container-Komponenten.

In meinem aktuellen Projektauftrag habe ich die Ehre, 4 Teams dabei zu helfen, die Codequalität zu verbessern und häufiger zu veröffentlichen. Leider gibt es nicht viele dumme Komponenten, die sich leichter testen und für die man Stories schreiben kann.

Es gibt noch kein Sicherheitsnetz (Tests + Stories), so dass das Refactoring ziemlich riskant ist. Das perfekte Huhn-und-Ei-Problem! Wie kann ich diese Komponenten trotzdem testen? Wie kann ich den Vuex-Speicher überlisten?

Da es sich um ein VueJS/Nuxt-Projekt handelt, haben wir mit der Verwendung von Vue Test Utils mit Jest begonnen.
Ich habe mich auch für die Verwendung von Storybook entschieden - insbesondere für die gemeinsamen Komponenten.

Die Beispielkomponente für diesen Blog-Beitrag heißt s-breadcrumbs und ist nur ein Wrapper für v-breadcrumbs.
Leider ist sie direkt mit dem globalen Speicher verbunden, so dass ich den Speicher nachahmen muss.

Die Dokumentation für Jest und Storybook ist ziemlich klar, wie man alles einrichtet, aber trotzdem hatte ich einige Probleme mit dem Mocking des Vuex Stores. Es scheint einige Unterschiede zwischen Storybook und Vue Test Utils zu geben.
Es steht alles in der Dokumentation, aber wenn Sie sie nicht sorgfältig gelesen haben, werden Sie wie ich stundenlang frustriert sein.

Einheitstest s-breadcrumbs

Unsere Komponente holt sich this.$store.getters.breadcrumbs (was in der Tat eine berechnete Eigenschaft ist) und gibt diesen Wert über die Eigenschaft items an v-breadcrumbs weiter. Natürlich passiert in unserer Komponente noch mehr, aber das ist nicht relevant.

Hier ist ein einfacher Unit-Test-Stub:

Ähnlich wie bei vue-router müssen wir Unit-Tests mit Vuex einrichten, indem wir im Test-Setup nicht Vue.use(Vuex) aufrufen, sondern eine localVue-Instanz verwenden. Auf diese Weise verhindern wir, dass das Test-Setup zu anderen Tests durchdringt, so dass andere Tests nicht vom aktuellen Test beeinflusst werden.

Hier gibt es einige Boilerplate, und wir wollen uns nicht wiederholen. Deshalb habe ich den Store und die localVue-Sachen in einen Mock-Helper extrahiert, der in alle Tests importiert werden kann, in denen der Vuex-Store gemockt werden soll:

Geschichte für s-breadcrumbs

Das Schreiben von Stories ist in der Regel weniger aufwändig als das Schreiben von Unit-Tests, da Sie keine Assertions schreiben müssen. Sie müssen nur ein paar Stories erstellen (die wahrscheinlich ein paar Regler enthalten) und für den Rest steht dem Benutzer eine schöne interaktive Komponente zur Verfügung, die im Browser läuft. Deshalb möchte ich Entwickler immer dazu ermutigen, parallel zu Unit-Tests auch Stories zu schreiben.

Hier ist eine einfache Geschichte für unsere Komponente s-breadcrumbs:

Denken Sie daran, dass die Komponente einen Speicher erwartet, so dass dies einen Fehler auslöst: this.$store is undefined. Lassen Sie uns den Store simulieren, sonst ist er in der Komponente nicht verfügbar.

Wir kommen der Sache schon näher. Der Store ist gemockt, aber das Vuex-Plugin ist noch nicht in Vue geladen. Wir müssen Vue.use(Vuex) in .storybook/config.js aufrufen. Dadurch wird die Eigenschaft $store zu allen Vue-Komponenten hinzugefügt, da alle Komponenten prototypisch von Vue erben.

Dies ist ein wichtiger Unterschied zu den Unit-Tests, da wir hier nicht eine Komponente isoliert ausführen. Stattdessen führen wir eine vollwertige Vue-Anwendung aus, die nur einen einfachen Komponentenbaum enthält. Die Wurzel dieses Baums ist die als Storybook-Konfiguration definierte Komponente. Das erste Kind ist die Komponente, für die wir die Geschichte schreiben: s-breadcrumbs.
Da unsere Komponente Zugriff auf den Store benötigt, müssen wir ihn von seinem Elternteil erben.

Wenn wir Vuex auf der Instanz localVue initialisieren würden, wäre der Mock Store nur auf der Storybook-Komponente verfügbar, nicht auf s-breadcrumbs.

Fazit

Es gibt 2 wesentliche Unterschiede zwischen dem Mocking des Vuex-Stores in Vue Test Utils und Storybook.

• In Storybook rufen Sie einfach Vue.use(Vue) in der Storybook-Konfigurationsdatei auf und fügen der Eigenschaft store in der Story einen Mock Store hinzu. Dies ist ähnlich wie bei der Einrichtung einer Anwendung. Im Grunde ist eine Story nur eine kleine Anwendung.
• In Vue Test Utils kompilieren und mounten Sie die Komponente direkt, so dass der Mocked Store in der Eigenschaft store definiert ist und als Ergebnis in der Komponente unter this.$store verfügbar ist. Sie müssen Vuex auf einer lokalen Kopie von Vue einrichten, um zu verhindern, dass Änderungen am globalen Vue Konstruktor vorgenommen werden und diese Vue-Instanz über die Einbindungsoptionen zusammen mit dem Mock-Store übergeben.