Schreiben eines API-Wrappers in Ruby mit TDD

() translation by (you can also view the original English article)

Früher oder später müssen alle Entwickler mit einer API interagieren. Der schwierigste Teil bezieht sich immer auf das zuverlässige Testen des von uns geschriebenen Codes. Da wir sicherstellen möchten, dass alles ordnungsgemäß funktioniert, führen wir kontinuierlich Code aus, der die API selbst abfragt. Dieser Prozess ist langsam und ineffizient, da Netzwerkprobleme und Dateninkonsistenzen auftreten können (die API-Ergebnisse können sich ändern). Sehen wir uns an, wie wir all diese Anstrengungen mit Ruby vermeiden können.

Unser Ziel

"Der Ablauf ist wichtig: Schreiben Sie die Tests, führen Sie sie aus und sehen Sie, dass sie fehlschlagen. Schreiben Sie dann den minimalen Implementierungscode, damit sie erfolgreich sind. Wenn alle dies tun, überarbeiten Sie sie bei Bedarf."

Unser Ziel ist einfach: Schreiben Sie einen kleinen Wrapper um die Dribbble-API, um Informationen über einen Benutzer abzurufen (in der Dribbble-Welt als "Player" bezeichnet). Da wir Ruby verwenden werden, werden wir auch einen TDD-Ansatz verfolgen: Wenn Sie mit dieser Technik nicht vertraut sind, verfügt Nettuts+ über eine gute Grundierung für RSpec, die Sie lesen können. Kurz gesagt, wir werden Tests schreiben, bevor wir unsere Code-Implementierung schreiben, um Fehler zu erkennen und eine hohe Codequalität zu erzielen. Der Ablauf ist wichtig: Schreiben Sie die Tests, führen Sie sie aus und sehen Sie, dass sie fehlschlagen. Schreiben Sie dann den minimalen Implementierungscode, damit sie bestanden werden. Sobald sie alle fertig sind, überarbeiten Sie sie bei Bedarf.

Die API

Die Dribbble-API ist ziemlich einfach. Zum jetzigen Zeitpunkt werden nur GET-Anforderungen unterstützt und es ist keine Authentifizierung erforderlich: ein idealer Kandidat für unser Lernprogramm. Darüber hinaus bietet es ein Limit von 60 Anrufen pro Minute, eine Einschränkung, die perfekt zeigt, warum die Arbeit mit APIs einen intelligenten Ansatz erfordert.

Schlüssel Konzepte

In diesem Tutorial muss davon ausgegangen werden, dass Sie mit den Testkonzepten vertraut sind: Vorrichtungen, Verspottungen, Erwartungen. Testen ist ein wichtiges Thema (insbesondere in der Ruby-Community). Auch wenn Sie kein Rubyist sind, möchte ich Sie ermutigen, sich eingehender mit der Angelegenheit zu befassen und nach gleichwertigen Tools für Ihre Alltagssprache zu suchen. Vielleicht möchten Sie das „RSpec-Buch“ von David Chelimsky et al. lesen, eine hervorragende Einführung in die verhaltensgesteuerte Entwicklung.

Um hier zusammenzufassen, sind hier drei Schlüsselkonzepte, die Sie kennen müssen:

Mock: Auch Double genannt, ist ein Mock „ein Objekt, das in einem Beispiel für ein anderes Objekt steht“. Das heißt, wenn wir die Interaktion zwischen einem Objekt und einem anderen testen wollen, können wir das zweite verspotten. In diesem Tutorial werden wir die Dribbble-API verspotten. Um unseren Code zu testen, benötigen wir nicht die API selbst, sondern etwas, das sich so verhält und dieselbe Schnittstelle verfügbar macht.
Fixture: Ein Datensatz, der einen bestimmten Status im System neu erstellt. Ein Fixture kann verwendet werden, um die erforderlichen Daten zum Testen einer Logik zu erstellen.
Erwartung: Ein Testbeispiel, das aus der Sicht des Ergebnisses geschrieben wurde, das wir erreichen wollen.

Unsere Werkzeuge

"Führen Sie in der Regel jedes Mal Tests durch, wenn Sie sie aktualisieren."

WebMock ist eine Ruby-Verspottungsbibliothek, die zum Verspotten (oder Stubben) von http-Anforderungen verwendet wird. Mit anderen Worten, Sie können damit jede HTTP-Anforderung simulieren, ohne tatsächlich eine zu erstellen. Der Hauptvorteil dabei besteht darin, dass jeder HTTP-Dienst entwickelt und getestet werden kann, ohne dass der Dienst selbst benötigt wird und ohne dass damit verbundene Probleme (wie API-Beschränkungen, IP-Einschränkungen usw.) auftreten.VCR ist ein ergänzendes Tool, das jede echte http-Anfrage aufzeichnet und ein Fixture erstellt, eine Datei, die alle erforderlichen Daten enthält, um diese Anfrage zu replizieren, ohne sie erneut auszuführen. Wir werden es so konfigurieren, dass WebMock verwendet wird, um dies zu tun. Mit anderen Worten, unsere Tests werden nur einmal mit der echten Dribbble-API interagieren: Danach stummelt WebMock dank der vom Videorecorder aufgezeichneten Daten alle Anforderungen. Wir werden eine perfekte Nachbildung der lokal aufgezeichneten Dribbble-API-Antworten haben. Darüber hinaus können wir mit WebMock Edge-Fälle (wie das Zeitlimit für Anforderungen) einfach und konsistent testen. Eine wunderbare Folge unseres Setups ist, dass alles extrem schnell sein wird.

Für Unit-Tests verwenden wir Minitest. Es handelt sich um eine schnelle und einfache Unit-Testing-Bibliothek, die auch die Erwartungen in RSpec-Manier unterstützt. Es bietet einen kleineren Funktionsumfang, aber ich finde, dass dies Sie tatsächlich ermutigt und dazu drängt, Ihre Logik in kleine, testbare Methoden zu unterteilen. Minitest ist Teil von Ruby 1.9. Wenn Sie es also verwenden (ich hoffe es), müssen Sie es nicht installieren. Bei Ruby 1.8 ist es nur eine Frage von gem install minitest.

Ich werde Ruby 1.9.3 verwenden: Wenn Sie dies nicht tun, werden Sie wahrscheinlich auf einige Probleme im Zusammenhang mit require_relative stoßen, aber ich habe Fallback-Code in einen Kommentar direkt darunter eingefügt. Im Allgemeinen sollten Sie Tests jedes Mal ausführen, wenn Sie sie aktualisieren, auch wenn ich diesen Schritt im gesamten Tutorial nicht explizit erwähne.

Installieren

Wir werden die konventionelle Ordnerstruktur /lib und /spec verwenden, um unseren Code zu organisieren. Der Name unserer Bibliothek wird nach der Dribbble-Konvention zur Verwendung von Begriffen im Zusammenhang mit Basketball als Dish bezeichnet.

Das Gemfile enthält alle unsere Abhängigkeiten, auch wenn sie recht klein sind.

source :rubygems

gem 'httparty'

group :test do
  gem 'webmock'
  gem 'vcr'
  gem 'turn'
  gem 'rake'
end

Httparty ist ein einfach zu verwendendes Juwel, um HTTP-Anfragen zu bearbeiten. Es wird der Kern unserer Bibliothek sein. In der Testgruppe werden wir auch Turn hinzufügen, um die Ausgabe unserer Tests so zu ändern, dass sie aussagekräftiger ist und Farbe unterstützt.

Die Ordner /lib und /spec haben eine symmetrische Struktur: Für jede Datei im Ordner /lib/dish sollte sich eine Datei in /spec/dish mit demselben Namen und dem Suffix "_spec" befinden.

Beginnen wir mit der Erstellung einer Datei /lib/dish.rb und fügen den folgenden Code hinzu:

1	require "httparty"
2	Dir[File.dirname(__FILE__) + '/dish/*.rb'].each do \|file\|
3	require file
4	end

Es macht nicht viel: Es erfordert "httparty" und iteriert dann über jede .rb-Datei in /lib/dish, um es zu benötigen. Mit dieser Datei können wir alle Funktionen in separaten Dateien in /lib/dish hinzufügen und automatisch laden, indem wir nur diese einzelne Datei benötigen.

Wechseln wir in den Ordner /spec. Hier ist der Inhalt der Datei spec_helper.rb.

#we need the actual library file
require_relative '../lib/dish'
# For Ruby < 1.9.3, use this instead of require_relative
# require(File.expand_path('../../lib/dish', __FILE__))

#dependencies
require 'minitest/autorun'
require 'webmock/minitest'
require 'vcr'
require 'turn'

Turn.config do |c|
 # :outline  - turn's original case/test outline mode [default]
 c.format  = :outline
 # turn on invoke/execute tracing, enable full backtrace
 c.trace   = true
 # use humanized test names (works only with :outline format)
 c.natural = true
end

#VCR config
VCR.config do |c|
  c.cassette_library_dir = 'spec/fixtures/dish_cassettes'
  c.stub_with :webmock
end

Hier gibt es einige bemerkenswerte Dinge, also lasst es uns Stück für Stück brechen:

Zunächst benötigen wir die Hauptbibliotheksdatei für unsere App, damit der zu testende Code der Testsuite zur Verfügung steht. Die Anweisung require_relative ist eine Ergänzung zu Ruby 1.9.3.
Wir benötigen dann alle Bibliotheksabhängigkeiten: minitest/autorun enthält alle Erwartungen, die wir verwenden werden, webmock/minitest fügt die erforderlichen Bindungen zwischen den beiden Bibliotheken hinzu, während vcr und turn ziemlich selbsterklärend sind.
Der Turn-Konfigurationsblock muss lediglich unsere Testausgabe optimieren. Wir werden das Gliederungsformat verwenden, in dem wir die Beschreibung unserer Spezifikationen sehen können.
Die VCR-Konfigurationsblöcke weisen VCR an, die Anforderungen in einem Fixture-Ordner zu speichern (beachten Sie den relativen Pfad) und WebMock als Stubbing-Bibliothek zu verwenden (VCR unterstützt einige andere).

Zu guter Letzt das Rakefile, das Support-Code enthält:

require 'rake/testtask'

Rake::TestTask.new do |t|
  t.test_files = FileList['spec/lib/dish/*_spec.rb']
  t.verbose = true
end

task :default => :test

Die rake/testtask-Bibliothek enthält eine TestTask-Klasse, mit der Sie den Speicherort unserer Testdateien festlegen können. Von nun an geben wir zum Ausführen unserer Spezifikationen nur noch rake aus dem Stammverzeichnis der Bibliothek ein.

Um unsere Konfiguration zu testen, fügen wir /lib/dish/player.rb den folgenden Code hinzu:

1	module Dish
2	class Player
3	end
4	end

Dann /spec/lib/dish/player_spec.rb:

require_relative '../../spec_helper'
# For Ruby < 1.9.3, use this instead of require_relative
# require (File.expand_path('./../../../spec_helper', __FILE__))

describe Dish::Player do

  it "must work" do
    "Yay!".must_be_instance_of String
  end

end

Wenn Sie rake ausführen, sollten Sie einen Test bestehen und keine Fehler machen. Dieser Test ist für unser Projekt keineswegs nützlich, überprüft jedoch implizit, ob unsere Bibliotheksdateistruktur vorhanden ist (der describe-Block würde einen Fehler auslösen, wenn das Dish::Player-Modul nicht geladen würde).

Erste Spezifikationen

Um richtig zu funktionieren, benötigt Dish die Httparty-Module und die richtige base_uri, d. h. Die Basis-URL der Dribbble-API. Schreiben wir die relevanten Tests für diese Anforderungen in player_spec.rb:

...
describe Dish::Player do

  describe "default attributes" do

    it "must include httparty methods" do
      Dish::Player.must_include HTTParty
    end

    it "must have the base url set to the Dribble API endpoint" do
      Dish::Player.base_uri.must_equal 'http://api.dribbble.com'
    end

  end

end

Wie Sie sehen können, sind die Erwartungen von Minitest selbsterklärend, insbesondere wenn Sie ein RSpec-Benutzer sind: Der größte Unterschied besteht in der Formulierung, bei der Minitest "must/wont" gegenüber "should/should_not" bevorzugt.

Wenn Sie diese Tests ausführen, werden ein Fehler und ein Fehler angezeigt. Um sie zu bestehen, fügen wir player.rb unsere ersten Zeilen des Implementierungscodes hinzu:

module Dish

  class Player

    include HTTParty

    base_uri 'http://api.dribbble.com'

  end

end

Wenn Sie den rake erneut ausführen, sollten die beiden Spezifikationen angezeigt werden. Jetzt hat unsere Player-Klasse Zugriff auf alle Httparty-Klassenmethoden wie get oder post.

Aufzeichnung unserer ersten Anfrage

Da wir an der Player-Klasse arbeiten, benötigen wir API-Daten für einen Player. Die Dokumentationsseite der Dribbble-API zeigt, dass der Endpunkt zum Abrufen von Daten zu einem bestimmten Player http://api.dribbble.com/players/:id ist

Wie in der typischen Rails-Mode :id ist entweder die id oder der Benutzername eines bestimmten Spielers. Wir werden simplebits verwenden, den Benutzernamen von Dan Cederholm, einem der Dribbble-Gründer.

Um die Anforderung mit dem Videorecorder aufzuzeichnen, aktualisieren wir unsere Datei player_spec.rb, indem wir der Spezifikation direkt nach dem ersten den folgenden describe-Block hinzufügen:

  ...

  describe "GET profile" do

  before do
    VCR.insert_cassette 'player', :record => :new_episodes
  end

  after do
    VCR.eject_cassette
  end

  it "records the fixture" do
    Dish::Player.get('/players/simplebits')
  end

  end

end

Nach dem Ausführen von rake können Sie überprüfen, ob das Gerät erstellt wurde. Von nun an sind alle unsere Tests vollständig netzwerkunabhängig.

Der before-Block wird verwendet, um einen bestimmten Teil des Codes vor jeder Erwartung auszuführen: Wir verwenden ihn, um das VCR-Makro hinzuzufügen, mit dem ein Gerät aufgezeichnet wird, das wir als "Player" bezeichnen. Dadurch wird eine player.yml-Datei unter spec/fixtures/dish_cassettes erstellt. Mit der Option :record werden alle neuen Anforderungen einmal aufgezeichnet und bei jeder nachfolgenden identischen Anforderung erneut abgespielt. Als Proof of Concept können wir eine Spezifikation hinzufügen, deren einziges Ziel darin besteht, ein Gerät für das Profil von simplebits aufzuzeichnen. Die after-Direktive weist den Videorecorder an, die Kassette nach den Tests zu entfernen, um sicherzustellen, dass alles ordnungsgemäß isoliert ist. Die get-Methode für die Player-Klasse wird dank des Httparty-Moduls zur Verfügung gestellt.

Nach dem Ausführen von rake können Sie überprüfen, ob das Gerät erstellt wurde. Von nun an sind alle unsere Tests vollständig netzwerkunabhängig.

Abrufen des Spielerprofils

Jeder Dribbble-Benutzer hat ein Profil, das eine ziemlich umfangreiche Datenmenge enthält. Lassen Sie uns darüber nachdenken, wie unsere Bibliothek bei tatsächlicher Nutzung aussehen soll: Dies ist eine nützliche Methode, um unser DSL zu verfeinern. Folgendes möchten wir erreichen:

simplebits = Dish::Player.new('simplebits')
simplebits.profile
  => #returns a hash with all the data from the API
simplebits.username
  => 'simplebits'
simplebits.id
  => 1
simplebits.shots_count
  => 157

Einfach und effektiv: Wir möchten einen Player mithilfe seines Benutzernamens instanziieren und dann auf seine Daten zugreifen, indem wir Methoden für die Instanz aufrufen, die den von der API zurückgegebenen Attributen zugeordnet sind. Wir müssen mit der API selbst konsistent sein.

Lassen Sie uns jeweils eine Sache angehen und einige Tests schreiben, die sich auf das Abrufen der Spielerdaten von der API beziehen. Wir können unseren Block "GET-profile" so ändern, dass er Folgendes enthält:

describe "GET profile" do

  let(:player) { Dish::Player.new }

  before do
    VCR.insert_cassette 'player', :record => :new_episodes
  end

  after do
    VCR.eject_cassette
  end

  it "must have a profile method" do
    player.must_respond_to :profile
  end

  it "must parse the api response from JSON to Hash" do
    player.profile.must_be_instance_of Hash
  end

  it "must perform the request and get the data" do
    player.profile["username"].must_equal 'simplebits'
  end

end

Die let-Direktive oben erstellt eine Dish::Player-Instanz, die in den Erwartungen verfügbar ist. Als Nächstes möchten wir sicherstellen, dass unser Player über eine Profilmethode verfügt, deren Wert ein Hash ist, der die Daten aus der API darstellt. Als letzten Schritt testen wir einen Beispielschlüssel (den Benutzernamen), um sicherzustellen, dass wir die Anforderung tatsächlich ausführen.

Beachten Sie, dass wir uns noch nicht mit dem Festlegen des Benutzernamens befassen, da dies ein weiterer Schritt ist. Die minimal erforderliche Implementierung ist die folgende:

...
class Player

  include HTTParty

  base_uri 'http://api.dribbble.com'

  def profile
    self.class.get '/players/simplebits'
  end

end
...

Eine sehr kleine Menge Code: Wir verpacken nur einen get-Aufruf in die profile-Methode. Wir übergeben dann den fest codierten Pfad, um die Daten von simplebits abzurufen, Daten, die wir dank VCR bereits gespeichert hatten.

Alle unsere Tests sollten bestanden werden.

Benutzernamen einstellen

Nachdem wir nun eine funktionierende Profilfunktion haben, können wir uns um den Benutzernamen kümmern. Hier sind die relevanten Spezifikationen:

describe "default instance attributes" do

  let(:player) { Dish::Player.new('simplebits') }

  it "must have an id attribute" do
    player.must_respond_to :username
  end

  it "must have the right id" do
    player.username.must_equal 'simplebits'
  end

end

describe "GET profile" do

  let(:player) { Dish::Player.new('simplebits') }

  before do
    VCR.insert_cassette 'base', :record => :new_episodes
  end

  after do
    VCR.eject_cassette
  end

  it "must have a profile method" do
    player.must_respond_to :profile
  end

  it "must parse the api response from JSON to Hash" do
    player.profile.must_be_instance_of Hash
  end

  it "must get the right profile" do
    player.profile["username"].must_equal "simplebits"
  end

end

Wir haben einen neuen Beschreibungsblock hinzugefügt, um den Benutzernamen zu überprüfen, den wir hinzufügen möchten, und einfach die player-Initialisierung im GET profile-Block geändert, um die gewünschte DSL widerzuspiegeln. Wenn Sie die Spezifikationen jetzt ausführen, werden viele Fehler angezeigt, da unsere Player-Klasse bei der Initialisierung(vorerst) keine Argumente akzeptiert.

Die Implementierung ist sehr einfach:

...
class Player

  attr_accessor :username

  include HTTParty

  base_uri 'http://api.dribbble.com'

  def initialize(username)
    self.username = username
  end

  def profile
    self.class.get "/players/#{self.username}"
  end

end
...

Die initialize-Methode erhält einen Benutzernamen, der dank der oben hinzugefügten attr_accessor-Methode in der Klasse gespeichert wird. Wir ändern dann die Profilmethode, um das Benutzername-Attribut zu interpolieren.

Wir sollten alle unsere Tests noch einmal bestehen lassen.

Dynamische Attribute

Grundsätzlich ist unsere Bibliothek in einem ziemlich guten Zustand. Da das Profil ein Hash ist, können wir hier anhalten und es bereits verwenden, indem wir den Schlüssel des Attributs übergeben, für das wir den Wert erhalten möchten. Unser Ziel ist es jedoch, ein einfach zu verwendendes DSL zu erstellen, das für jedes Attribut eine Methode enthält.

Überlegen wir uns, was wir erreichen müssen. Nehmen wir an, wir haben eine Player-Instanz und geben an, wie das funktionieren würde:

player.username
  => 'simplebits'
player.shots_count
  => 157
player.foo_attribute
  => NoMethodError

Lassen Sie uns dies in Spezifikationen übersetzen und sie dem GET profile-Block hinzufügen:

...
describe "dynamic attributes" do

  before do
    player.profile
  end

  it "must return the attribute value if present in profile" do
    player.id.must_equal 1
  end

  it "must raise method missing if attribute is not present" do
    lambda { player.foo_attribute }.must_raise NoMethodError
  end

end
...

Wir haben bereits eine Spezifikation für den Benutzernamen, sodass wir keine weitere hinzufügen müssen. Beachten Sie einige Dinge:

Wir rufen player.profile explizit in einem Vorher-Block auf, andernfalls ist es Null, wenn wir versuchen, den Attributwert abzurufen.
Um zu testen, ob foo_attribute eine Ausnahme auslöst, müssen wir es in ein Lambda einschließen und überprüfen, ob es den erwarteten Fehler auslöst.
Wir testen, dass id gleich 1 ist, da wir wissen, dass dies der erwartete Wert ist (dies ist ein rein datenabhängiger Test).

In Bezug auf die Implementierung könnten wir eine Reihe von Methoden definieren, um auf den profil-Hash zuzugreifen. Dies würde jedoch eine Menge doppelter Logik erzeugen. Darüber hinaus würde sich das auf das API-Ergebnis verlassen, um immer die gleichen Schlüssel zu haben.

"Wir werden uns auf method_missing verlassen, um diese Fälle zu behandeln und all diese Methoden im laufenden Betrieb zu generieren."

Stattdessen werden wir uns auf method_missing verlassen, um diese Fälle zu behandeln und alle diese Methoden im laufenden Betrieb zu "generieren". Aber was bedeutet das? Ohne zu viel Metaprogrammierung zu betreiben, können wir einfach sagen, dass Ruby jedes Mal, wenn wir eine Methode aufrufen, die nicht für das Objekt vorhanden ist, einen NoMethodError mithilfe von method_missing auslöst. Indem wir genau diese Methode innerhalb einer Klasse neu definieren, können wir ihr Verhalten ändern.

In unserem Fall werden wir den Aufruf method_missing abfangen, überprüfen, ob der aufgerufene Methodenname ein Schlüssel im Profil-Hash ist, und im Falle eines positiven Ergebnisses den Hash-Wert für diesen Schlüssel zurückgeben. Wenn nicht, rufen wir super auf, um einen Standard-NoMethodError auszulösen: Dies ist erforderlich, um sicherzustellen, dass sich unsere Bibliothek genau so verhält, wie es jede andere Bibliothek tun würde. Mit anderen Worten, wir möchten die geringstmögliche Überraschung garantieren.

Fügen wir der Player-Klasse den folgenden Code hinzu:

def method_missing(name, *args, &block)
  if profile.has_key?(name.to_s)
    profile[name.to_s]
  else
    super
  end
end

Der Code macht genau das, was oben beschrieben wurde. Wenn Sie jetzt die Spezifikationen ausführen, sollten Sie sie alle bestehen lassen. Ich möchte Sie bitten, den Spezifikationsdateien weitere Elemente für ein anderes Attribut hinzuzufügen, z. B. shot_count.

Diese Implementierung ist jedoch nicht wirklich idiomatisch Ruby. Es funktioniert, kann aber zu einem ternären Operator optimiert werden, einer komprimierten Form einer If-else-Bedingung. Es kann wie folgt umgeschrieben werden:

1	def method_missing(name, *args, &block)
2	profile.has_key?(name.to_s) ? profile[name.to_s] : super
3	end

Es geht nicht nur um die Länge, sondern auch um Konsistenz und gemeinsame Konventionen zwischen Entwicklern. Das Durchsuchen des Quellcodes von Ruby-Edelsteinen und -Bibliotheken ist eine gute Möglichkeit, sich an diese Konventionen zu gewöhnen.

Caching

Als letzten Schritt möchten wir sicherstellen, dass unsere Bibliothek effizient ist. Es sollte nicht mehr Anfragen als nötig stellen und möglicherweise Daten intern zwischenspeichern. Lassen Sie uns noch einmal darüber nachdenken, wie wir es verwenden könnten:

player.profile
  => performs the request and returns a Hash
player.profile
  => returns the same hash
player.profile(true)
  => forces the reload of the http request and then returns the hash (with data changes if necessary)

Wie können wir das testen? Wir können WebMock verwenden, um Netzwerkverbindungen zum API-Endpunkt zu aktivieren und zu deaktivieren. Selbst wenn wir Videorecorder-Geräte verwenden, kann WebMock ein Netzwerk-Timeout oder eine andere Reaktion auf den Server simulieren. In unserem Fall können wir das Caching testen, indem wir das Profil einmal abrufen und dann das Netzwerk deaktivieren. Durch erneutes Aufrufen von player.profile sollten dieselben Daten angezeigt werden, während durch Aufrufen von player.profile(true) ein Timeout::Error angezeigt wird, da die Bibliothek versuchen würde, eine Verbindung zum (deaktivierten) API-Endpunkt herzustellen.

Fügen wir der Datei player_spec.rb direkt nach dynamic attribute generation einen weiteren Block hinzu:

describe "caching" do

  # we use Webmock to disable the network connection after
  # fetching the profile
  before do
    player.profile
    stub_request(:any, /api.dribbble.com/).to_timeout
  end

  it "must cache the profile" do
    player.profile.must_be_instance_of Hash
  end

  it "must refresh the profile if forced" do
    lambda { player.profile(true) }.must_raise Timeout::Error
  end

end

Die Methode stub_request fängt alle Aufrufe des API-Endpunkts ab und simuliert ein Timeout, wodurch der erwartete Timeout::Error ausgelöst wird. Wie zuvor testen wir das Vorhandensein dieses Fehlers in einem Lambda.

Die Implementierung kann schwierig sein, daher teilen wir sie in zwei Schritte auf. Verschieben wir zunächst die eigentliche http-Anforderung in eine private Methode:

...
def profile
  get_profile
end

...

private

def get_profile
  self.class.get("/players/#{self.username}")
end
...

Dadurch werden unsere Spezifikationen nicht weitergegeben, da das Ergebnis von get_profile nicht zwischengespeichert wird. Ändern Sie dazu die profile-Methode:

...
def profile
  @profile ||= get_profile
end
...

Wir werden den Ergebnis-Hash in einer Instanzvariablen speichern. Beachten Sie auch den Operator ||=, dessen Vorhandensein sicherstellt, dass get_profile nur ausgeführt wird, wenn @profile einen falschen Wert zurückgibt (wie nil).

Als nächstes können wir die Direktive zum erzwungenen Neuladen hinzufügen:

...
def profile(force = false)
  force ? @profile = get_profile : @profile ||= get_profile
end
...

Wir verwenden wieder ein Ternär: Wenn force falsch ist, führen wir get_profile aus und zwischenspeichern es. Wenn nicht, verwenden wir die in der vorherigen Version dieser Methode geschriebene Logik (dh führen die Anforderung nur aus, wenn wir noch keinen Hash haben ).

Unsere Spezifikationen sollten jetzt grün sein und dies ist auch das Ende unseres Tutorials.

Einpacken

Unser Ziel in diesem Tutorial war es, eine kleine und effiziente Bibliothek für die Interaktion mit der Dribbble-API zu schreiben. Wir haben den Grundstein dafür gelegt. Der größte Teil der von uns geschriebenen Logik kann abstrahiert und für den Zugriff auf alle anderen Endpunkte wiederverwendet werden. Minitest, WebMock und VCR haben sich als wertvolle Werkzeuge erwiesen, mit denen wir unseren Code gestalten können.

Wir müssen uns jedoch einer kleinen Einschränkung bewusst sein: Der Videorecorder kann zu einem zweischneidigen Schwert werden, da unsere Tests zu stark datenabhängig werden können. Wenn die API, die wir erstellen, aus irgendeinem Grund gegen Änderungen ohne sichtbares Zeichen (z. B. eine Versionsnummer) erstellt wird, besteht die Gefahr, dass unsere Tests perfekt mit einem Datensatz funktionieren, der nicht mehr relevant ist. In diesem Fall ist das Entfernen und Neuerstellen des Geräts der beste Weg, um sicherzustellen, dass unser Code weiterhin wie erwartet funktioniert.

1	describe "default instance attributes" do
2
3	let(:player) { Dish::Player.new('simplebits') }
4
5	it "must have an id attribute" do
6	player.must_respond_to :username
7	end
8
9	it "must have the right id" do
10	player.username.must_equal 'simplebits'
11	end
12
13	end
14
15	describe "GET profile" do
16
17	let(:player) { Dish::Player.new('simplebits') }
18
19	before do
20	VCR.insert_cassette 'base', :record => :new_episodes
21	end
22
23	after do
24	VCR.eject_cassette
25	end
26
27	it "must have a profile method" do
28	player.must_respond_to :profile
29	end
30
31	it "must parse the api response from JSON to Hash" do
32	player.profile.must_be_instance_of Hash
33	end
34
35	it "must get the right profile" do
36	player.profile["username"].must_equal "simplebits"
37	end
38
39	end