GexfVizz – Über JUnit und Testfälle

Nachdem nun der „Circos Teil“ meiner Bachelorarbeit soweit abgeschlossen ist (von ein paar Kleinigkeiten mal abgesehen) bin ich nun in den Bereich des Testens übergegangen. Mit anderen Worten beschäftige ich mich aktuell mit JUnit 4 und in wie weit man dies in meinem Projekt sinnvoll einsetzen kann.

Konzeption und agile Entwicklung einer REST-Schnittstelle für eine Rails-basierte Scientific Event Management Plattform

Mit der Präsentation ist meine Masterarbeit nun erfolgreich beendet. Ein Konzept, anhand dessen die ginkgo-API komplett entwickelt werden kann, ist im projekteigenen Wiki vorhanden. Der zugehörige Prototyp läuft seit einigen Wochen stabil und setzt Ressourcen in den Bereichen Nutzer, wissenschaftliche Veranstaltungen, private Nachrichten, Kurznachrichten und Activity Stream um.

Die rund 120 Features (dabei handelt es sich um vorhandene und gewünschte Funktionalitäten aus Nutzersicht) waren ein guter Startpunkt, um die für die REST-Schnittstelle benötigten Ressourcen und Repräsentationen herzuleiten.

Kombiniert man das RAILS-Framework mit einer Softwarekomponente, welche die Erstellung der Repräsentationen vereinfacht (z.B. ROAR), ist die Umsetzung einer REST-Schnittstelle sehr elegant möglich.

Mir persönlich hat es sehr viel Spaß gemacht, mit den für mich ganz neuen Technologien Rails und Ruby zu arbeiten und bedanke mich für die Unterstützung aus dem ginkgo-dev-Team!

Hier nun die Folien der Abschlusspräsentation:

 

OAuth2-Request in RSpec testen

Da mich die „Fehlersuche“ insgesamt 2 Tage beschäftigt hat und ich langsam glaube, dass ich für das Testen der ginkgo API insgesamt mehr Zeit gebraucht habe, als für die Implementierung, möchte ich zumindest eine Erkenntnis in die Welt streuen ;-) .

Während es in Cucumber-Tests sehr einfach ist einen authentifizierten OAuth2 HTTP-Request hinzubekommen (einfach nur den Authentication-Header setzen), gestaltet sich das in RSpec-Test schwerer. Das ist auch klar, weil viele helfende Komponenten von Rails richtigerweise nicht zum Einsatz kommen, um wirklich nur die aktuell betrachtete Komponente zu testen.

Um es kurz zu machen, für einen authentifizierten OAuth2 Request in RSpec-Tests benötigt das request-Objekt die beiden Parameter oauth.strategies und token. Also z.B. :

  def prepare_authenticated_access_token_request
# Create a valid, authorized access token
token = Oauth2Token.create :user => @resource_owner, :client_application => @client_application
# Configure the request object so that it is recognized as a OAuth request
request.env[„oauth.strategies“] = [:oauth20_token, :token]
request.env[„oauth.token“] = token
end

Für alle, die OAuth1-Requests erstellen wollen, sei auf configure_oauth eines TestRequests hingewiesen:

    ActionController::TestRequest.use_oauth=true
request.configure_oauth(@resource_owner,token)

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

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.