codecentric

Verbesserte JBehave Steps mit Varianten

April 2, 2012 von

In einem früheren Post wurde bereits eine kleine Einführung in das JBehave Projekt zur Automatisierung von Akzeptanztests gegeben. Während sich dieser Artikel mit der Installation und der allgemeinen Verwendung des Frameworks beschäftigte, konzentriere ich mich heute auf eine Erweiterung, die ich kürzlich zum Projekt beigesteuert habe, und die es erlaubt, Test Stories in noch natürlicherer Sprache abzufassen, als bislang möglich.

Bisher bei LOST JBehave

Ein kurzer Rückblick: In JBehave werden Tests in Sätzen in natürlicher Sprache verfasst, die zur Ausführungszeit auf korrespondierende Methoden abgebildet werden. Folgendes Beispiel stammt aus der JBehave Dokumentation (übersetzt):

@When("der Artikelpreis $preis ist")
@Aliases(values={"der Artikelpreis $preis beträgt"
             "der Artikelpreis $preis entspricht"}) // mehrere Aliase
public void derPreisIst(double preis) {
    // ...
}

Diese Methode wird aufgerufen, wenn in einer Test-Story eine der folgenden Zeilen steht:

  • Wenn der Artikelpreis 10 ist
  • Wenn der Artikelpreis 10 beträgt
  • Wenn der Artikelpreis 10 entspricht

Die Bereitstellung dieser verschiedenen Formulierungen, die jeweils das identische technische Verhalten auslösen, ist für Tester aus verschiedenen Gründen von großem Vorteil. Zunächst muss sich der Autor der Tests nicht exakt an die genaue Schreibweise eines Testschritts erinnern, um die gewünschte Operation auszulösen. Diesem Problem ließe sich mit besserer Editorunterstützung begegnen, z. B. mit dem JBehave Eclipse Plugin.

Darüber hinaus – und meiner Meinung nach ist dies der wichtigere Aspekt – erlaubt es, Test-Stories zu verfassen, die sowohl einfacher zu lesen, aber auch zu schreiben sind. Eine strikte Beschränkung auf genau eine gültige Formulierung pro Testschritt reißt Testautoren tendenziell aus dem Schreibfluss.

Im oben genannten Beispiel ist die Ähnlichkeit zwischen den drei Alternativen sehr deutlich. Sie beginnen alle mit der gleichen Einleitung, gefolgt von einer Variablen $preis, sowie einem jeweils unterschiedlichen Wort am Ende.

Diese Wiederholung von Text führt zu erheblicher Unordnung im Java Source und ist eine hervorragende Quelle für später schwer zu findende Copy und Paste Fehler.

(weiterlesen …)

Daniel Schneller

* Kategorie: Agiles Testen, Java | * 2 Kommentare
Geschrieben am April 2, 2012 von

 

SOAP Webservices mit iOS

Januar 2, 2012 von

Betrachtet man APIs für aktuelle Web-Plattformen wie Soziale Netzwerke, die Amazon Web Services, Fotodienste à la Flickr oder Instagram und zahllose mehr, so könnte der Eindruck entstehen, REST hätte als der Kommunikation mit entfernten Diensten zu Grunde liegende Architektur das häufig geschmähte und als überbordend und komplex verteufelte SOAP bereits seit langem abgelöst.

Allerdings ist dies nur auf den ersten Blick der Fall. Insbesondere unternehmensintern werden immer noch viele Dienste mittels SOAP abgebildet – insbesondere dort, wo es weniger auf das reine Abholen von Ressourcen oder verhältnismäßig einfache CRUD Operationen ankommt, sondern eher komplexe Datentypen mit einem reichhaltigen Typsystemen und validierbaren Funktionssignaturen im Vordergrund stehen.

Gleich vorab: In diesem Post soll es nicht darum gehen, die Vor- und Nachteile von SOAP und REST gegenüberzustellen oder zu diskutieren, ob die beiden Techniken grundsätzlich überhaupt verglichen werden sollten – damit haben sich andere bereits ausreichend beschäftigt.

Stattdessen geht es hier um die Fälle, in denen die Entscheidung für SOAP und gegen REST bereits gefallen ist, und in denen nun die Problemstellung zu lösen ist, eine iOS Anwendung zu entwickeln, die eben diese SOAP Dienste als Konsument verwenden kann.

Die Verwendung von SOAP hat zum Teil historische Gründe, bei denen die SOAP Schnittstellen bereits existierten, bevor REST populär wurde. Mitunter ist es aber auch eine bewusste Entscheidung, um für interne wie externe Clients über WSDL und etablierte Frameworks eine wohldefinierte und formal prüfbare Schnittstelle anzubieten.

(weiterlesen …)

Daniel Schneller

* Kategorie: Java, Mobile | * 2 Kommentare
Geschrieben am Januar 2, 2012 von

 

Warum gute Metriken nicht gleichbedeutend mit guter Qualität sind

Oktober 4, 2011 von

Mit einiger Regelmäßigkeit führen codecentric Experten Reviews und Qualitätsgutachten von Softwareprodukten durch. Im Fokus der Betrachtung stehen dabei zum Beispiel Gewerke, die der Auftraggeber nach Erhalt durch nicht an der Entwicklung Beteiligte begutachtet wissen möchte, oder auch In-House Lösungen, über deren aktuellen Zustand sich der Kunde ein Bild verschaffen will.

Dabei wird häufig angenommen, dass mittels automatischer Tools bereits ein ausreichend verlässlicher Eindruck von der Qualität und Wartbarkeit einer Software gewonnen werden kann, und sich damit ein aufwändiger manueller Review einsparen lässt. Anhand eines vereinfachten Beispiels soll hier erklärt werden, dass es sich hierbei um einen Irrtum handelt, und dass maschinell erstellte Metriken keineswegs ein Ersatz für eine manuelle Untersuchung sein können.

Metriken und Werkzeuge

Am Anfang einer Codeanalyse werden üblicherweise in der Tat zunächst maschinell Metriken ermittelt, um sich einen ersten Eindruck des Betrachtungsgegenstands Softwareprodukt zu verschaffen. Dabei bedient man sich oft im ersten Schritt “klassischer” Werte – um bspw. den Umfang des Produkts überblicken zu können (Zahl der Packages, Klassen, Methoden, Codezeilen) –  als auch bekannter Qualitätsmetriken, wie z. B. der zyklomatischen Komplexität (Cyclomatic Complexity).

All diese Werte lassen sich mit diversen kostenlosen wie kommerziellen Werkzeugen zügig ermitteln und basieren auf einer automatischen Analyse des Quelltexts bzw. der Java Klassen.

Sobald sie zur Verfügung stehen, lassen sich die konkreten Ergebnisse mit Referenzwerten vergleichen, z. B. denen der Carnegie Mellon University für die zyklomatische Komplexität. (weiterlesen …)

Daniel Schneller

* Kategorie: Clean Code, Java | * 1 Kommentar
Geschrieben am Oktober 4, 2011 von

 



Publikationen