Ginkgo-API: Testgetrieben läuft’s am besten

15 Mrz

Ginkgo wurde von Beginn an testgetrieben entwickelt. Dieses Verhalten wird auch bei der API-Entwicklung beibehalten.

Bei der testgetriebenen Softwareentwicklung stellt ein Test mehr dar, als nur die Verifikation der Korrektheit von Programm-Quellcode. Ein Test gilt als Startpunkt, von dem ausgehend ein System in kleinen Schritten mit zusätzlichen Funktionalitäten angereichert wird.

Allerdings kann selbst die beste, nach diesen Maßstäben entwickelte Softwarekomponente auch einfach das Falsche umsetzen. Dies kann durch sich teilweise überlagernde Komponenten-und Akzeptanztest verhindert werden. Während Komponententests für einen isoliert betrachteten Programmteil seine technische Lauffähigkeit und fachliche Korrektheit bescheinigen, gewährleisten Akzeptanztests, dass sich das Gesamtsystem (meistens dem Anwender gegenüber) richtig verhält.

In Ruby ist RSpec der Standard für Komponententests. Die ginkgo-API testet:

  • Models (Klassen, die OAuth-Tokens und registrierte API-Konsumenten speichern sowie Klassen in denen Berechtigungen gespeichert sind (CanCan))
  • Controller (alle API-Controller)

Für Akzeptanztests kommt Cucumber zum Einsatz. Da im Endeffekt nur der Anwender selbst (bzw. ein Auftraggeber) das korrekte Verhalten der Software definieren kann, bietet es sich an, dies in einer für beide (Auftraggeber und Entwickler) verständlichen Sprache zu tun. So entstehen sogenannte Features, die automatisiert ausgeführt werden und die gegebenen Textbausteine in Methodenaufrufe auf zu testende Softwarekomponenten überführen:

Feature: List users
In order to search for other ginkgo users
As an API consumer
I want to retrieve a list of ginkgo users

Background:
Given I use a HTTP client
Given I accept version 1 of the ginkgo mime type

Scenario: Retrieving users
Given I have a valid „Access Token“
When I send a GET request to the base URL
And I follow the link with the name „https://api.ginkgosem.com/rels/collection/user“
Then the response code should be „200“
And the representation should contain a field named „type“ with value „https://api.ginkgosem.com/rels/user“

Aktuell führen Komponenten- und Akzeptanztests zu einer Testabdeckung von 86% (allerdings für den gesamten ginkgo-Quellcode). Es fehlen aber noch ein paar Controller-Tests. Wie man sieht, wurde also nicht ganz testgetrieben enwickelt.

Der Grund hierfür ist, dass zu Beginn Designentscheidungen in Tests nur schwer getroffen werden konnten, weil noch große Unsicherheit bei den einzusetzenden Technologien bestand. Zudem musste ginkgo mobile schnell mit Daten versorgt werden und der Aufwand um Tests zu schreiben ist mindestens doppelt so hoch, wie die Funktionen zu programmieren. Mit zunehmender Erfahrung in Sachen Test, relativiert sich dieses Verhältnis ganz sicher.

Obwohl diese Art von Entwicklung wirklich Disziplin erfordert, stellt sie zu jeden Zeitpunkt die Lauffähigkeit der gesamten Software sicher und hilft dabei genau das zu machen, was ein Auftraggeber auch will.

2 Antworten to “Ginkgo-API: Testgetrieben läuft’s am besten”

  1. Michael Whittaker 15. März 2012 um 11:44 #

    Interessant! Wie überprüfst du dein JSON? Hast du die Step Definitions selbst geschrieben oder lässt du dir von einem Plugin helfen?
    Ich benutze zur Zeit für JSON https://github.com/collectiveidea/json_spec, finde aber, dass man da noch einiges dran verbessern könnte…
    Oder ist das eine XML-API?

    • chrisupb 15. März 2012 um 14:01 #

      Ich nutze in der Tat json_spec- allerdings nur in den Komponententests (also den specs).

      Mein Vorgehen:
      In den Specs für die Representer (welche die Repräsentationen generieren) teste ich jedes einzelne Feld der JSON-Repräsentationen.

      In den Akzeptanztests (Features) teste ich eher, dass das Richtige passiert und prüfe nur stichprobenartig, ob einzelne Felder richtige Werte beinhalten. Sonst wären die Features voll mit „And the representation should contain a field named “email” with value “John@example.org”“…
      Die Step Definitions sind alle selbst entwickelt. Mit ca. 15 Steps kann man schon die meisten Anwendungsfälle umsetzten.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: