Als Entwickler versuche ich ständig, meinen Code zu verbessern. Auch in Bezug auf die Tests. Für mich ist es wichtig, Tests sauber zu halten, damit das Hinzufügen neuer Tests ein Vergnügen und keine Plackerei ist.

Das erste Mal stolperte ich über den geteilten Kontext, als ich nach etwas suchte, das mir helfen kann, einige ständig wiederkehrende Variablen in Tests zu extrahieren. Der geteilte Kontext war genau das, wonach ich gesucht hatte. Ich werde Ihnen zeigen, wie man ihn verwendet und welche Vorteile das hat.

Was testen wir?

{

Angenommen, wir müssen ein paar Policy-Objekte schreiben. Sie können wie das folgende aussehen:

Wir haben irgendwo Benutzer definiert und UserSettings Klassen, deren Instanzen durch user_id verbunden sind. Sie können ActiveRecord-Objekten und einer Datenbankbeziehung ähneln oder sie können Objekte sein, die auf Ereignissen basieren. Danach können wir mit dem Schreiben von Tests beginnen. In diesem Beispiel werden Vorname, Nachname und E-Mail zur Erstellung eines Benutzerobjekts benötigt.

Um das Richtlinienobjekt zu testen, benötigen wir einen Admin-Benutzer und einen Benutzer, der Eigentümer einer Ressource ist. Offensichtlich auch die Ressource.

Sie müssen zugeben, dass diese lets etwas stattgefunden haben. Ok, wir können uns um das Testen des nächsten Richtlinienobjekts kümmern. Hmmmm... das bedeutet, dass wir den Benutzer und den Admin in der nachfolgenden Spezifikationsdatei deklarieren müssen. Das ist 'nicht der richtige Weg.

It's time for the shared context

I've das Verzeichnis shared innerhalb des Katalogs spec erstellt. Innerhalb dieses Katalogs habe ich die Datei users erstellt. Ich habe sie so benannt, um den Inhalt der Datei genau zu spezifizieren.

Der Inhalt dieser Datei enthält let{s, die wir zuvor in der policy spec-Datei gesehen haben. Der einzige Unterschied ist, dass ich ids in separate Variablen extrahiert habe, weil ich nicht jedes Mal [user.id](http://user.id) verwenden möchte. Es gibt noch eine Sache zu tun, wir müssen den geteilten Kontext in der spec_helper.rb Datei laden, wie so:

{

Die Zeile oben lädt alle .rb Dateien aus dem shared Verzeichnis.

{

Damit können wir anfangen den gemeinsamen Kontext zu benutzen, was ziemlich einfach ist. Werfen wir einen Blick auf die Spec-Datei. Jetzt ist es klarer, oder?

Wie Sie feststellen konnten, müssen wir den Kontext mit include_context :users einschließen. Danach können wir alles verwenden, was wir in unserer Kontextdatei definiert haben. Jetzt können wir ein weiteres Policy-Objekt und Tests dafür schreiben, ohne die Benutzerdeklarationen zu duplizieren.

Zusammenfassung

{

Der gemeinsame Kontext ist ein guter Ort, um Variablen zu platzieren, die wir in mehr als einer Spec-Datei verwenden. Bei Bedarf können Sie auch Mocks in Ihrem Kontext ablegen. Manchmal ist es schwer, einen gemeinsamen Kontext zu schreiben, der keine unbenutzten Variablen enthält, aber keine Sorge, unbenutzte Variablen sind let{s und sie werden initialisiert, wenn man sie in einer Testdatei benutzt. Trotzdem empfehle ich Ihnen, kleine gemeinsame Kontexte zu schreiben, um einfach nur das einzubinden, was Sie brauchen, und die richtige Benennung der Kontextdateien beizubehalten.