Von der Service-Virtualisierung profitieren

Bild 1: Schnelle Übersicht über vorhandene Virtual Assets liefert die Testumgebung Parasoft Virtualize, und erleichtert so die Zusammenarbeit der Entwickler. Parasoft

Wenn Entwickler Code schreiben, kommunizieren sie häufig mit denselben externen APIs und führen auf unterschiedliche Weise dieselben Aufrufe auf dieselben Dienste aus. Das Problem bei traditionellen Mocks besteht darin, dass sie auf der Code-Ebene geschrieben und speziell für die gerade in der Entwicklung befindliche Funktion ausgelegt sind. Als Folge ist jedes Mal, wenn die betreffende Funktionalität ausgeführt werden muss, ein neues Mock-Objekt zu erstellen.

Kommt ein traditionelles Mocking-Framework zum Einsatz, gestaltet sich das Teilen bereits existierender Mocks kompliziert. Das hat zwei Gründe: Zum einen ist nicht unbedingt bekannt, wo sich die Mocks in der Codebasis befinden. Zum anderen ist es schwer nachvollziehbar, mit welcher Anforderung ein bestimmtes Mock-Objekt verknüpft ist. Dies führt dazu, dass Teammitglieder häufig dieselben Mocks erstellen wie der/die Kollege/in gleich nebenan. Hier wird also viel Zeit und Arbeit der Entwickler vergeudet.

Wo ist mein Mock?

Eine weitere Herausforderung stellt das Zusammenarbeiten dar, wenn ein Entwickler ein Mock-Objekt erstellt hat. Schließlich gibt es kein magisches schwarzes Brett, an dem man Nachrichten über bereits erstellte Mocks hinterlassen kann, um das Team auf dem Laufenden zu halten.

Ein Beispiel: In einem im Gesundheitswesen tätigen Unternehmen ist das Mocking in der Entwicklung gängige Praxis. Weil der gemeinsame Service Provider dieses Unternehmens ständig offline ging, war er häufig Gegenstand des Mockings. Jeder einzelne Entwickler hatte somit in seiner Codebasis eine durch Mocking simulierte Schnittstelle zu diesem Provider erstellt. Alle diese Mocks wiesen geringfügige Unterschiede auf, dienten aber demselben Zweck. In Gesprächen mit den Entwicklern stellte sich heraus, dass etwa 20 gleichartige Mocks existierten – eine Überraschung sogar für die Entwickler selbst. Die Nachfrage nach dieser Doppelarbeit führte zur nicht ganz unerwarteten Antwort in verhaltenem Ton: „Wir waren viel zu beschäftigt, um miteinander zu kommunizieren“.

Bild 2: Die zeit- und ortsunabhängige Zusammenarbeit durch Zugriff auf eine komplette Testumgebung ermöglichen moderne Tools wie Parasoft Virtualize, eine offene automatisierte Service-Virtualisierungslösung. Parasoft

Natürlich sind Mocks notwendig, wie jeder Entwickler oder Tester bestätigen wird, denn man benötigt bei der Entwicklungsarbeit eine Möglichkeit, sich von der übrigen Welt zu entkoppeln. Mocks stellen einen Weg dar, die zu entwickelnde Applikation mit einer Umgebung zu versehen, die sich absichern lässt. Allerdings birgt diese Lösung durchaus Herausforderungen, wie diese Beispiele zeigen:

• Jedes Mock-Objekt von Grund auf neu zu erstellen ist mühsam und zeitraubend.
• Es ist schwierig, bereits existierende Mocks aufzufinden.
• Mocks existieren zweckfrei; sie sind nicht mit bestimmten APIs verknüpft und nicht wiederverwendbar.
• Die Leute sind zu beschäftigt, um sich auszutauschen, obwohl sie wissen, dass sie eigentlich zusammenarbeiten müssen.

Fortwährendes Erstellen immer neuer virtueller Services

Glücklicherweise gibt es moderne Lösungen für die Herausforderungen der Kollaboration: So vereinfacht Parasoft Virtualize das Betreiben einer Mocking-Lösung, indem es das Erstellen einer ganzen Bibliothek wiederverwendbarer virtueller Services mit einer gemeinsamen zentralen Funktionalität ermöglicht. Als Beispiel sei ein bestehender Service angenommen, der Informationen über die Identität einer Person zur Verfügung stellt, indem er auf die Eingabe einer Kontonummer mit Daten über die zugehörige Person antwortet. Nun soll ein neuer virtueller Service entwickelt werden, der auf der Grundlage der Kontonummer mit detaillierten finanziellen Angaben antwortet. Mit Virtualize kann beim Entwickeln des neuen virtuellen Services auf einen großen Teil des ursprünglichen Services zurückgegriffen werden. Das einzige, was beide unterscheidet, sind das Schema und die Daten. Wenn nun ein Unternehmen immer mehr virtuelle Services erstellt, wächst damit automatisch auch der Bestand an wiederverwendbaren Artefakten. Somit muss ein und derselbe virtuelle Service nicht länger immer wieder neu entwickelt werden.

Das Teilen virtueller Services

Nicht nur virtuelle Services an sich eignen sich sehr gut für das Teilen, sondern auch die internen Module lassen sich wiederverwenden. Virtuelle Services oder pva-Dateien können im XML-Format abgespeichert und einfach in die Source Control geladen werden. Wenn der Service eine bestimmte Funktionalität für ein bestimmtes API simuliert, ist die Suche nach dem jeweiligen Artefakt möglich, und zwar entweder in Source Control oder – was noch einfacher ist – in einem gemeinsam genutzten Virtualisierungs-Server. Je mehr ein Team in die Nutzung der Service-Virtualisierung hineinwächst, umso mehr kann es auf die bestehenden Server-Sharing-Fähigkeiten zurückgreifen, indem der jeweilige Desktop direkt mit dem Server verbunden wird. So lässt sich nach dem jeweils benötigten Artefakt suchen, um es nach dem Auffinden direkt auf den eigenen Desktop zu ziehen und umgehend einzusetzen. Hierdurch wird das Problem des Entdeckens von bereits entwickelten virtuellen Services und des unmittelbaren Zugriffs auf diese Services gelöst.

Die Verknüpfung virtueller Services miteinander

Bild 3: Indem die Service Virtualisierung eine Entwicklungstestumgebung simuliert, bietet sie viele Vorteile für die Zusammenarbeit im Team. Parasoft

Die Testumgebung Parasoft Virtualize ist von überall und jederzeit zugänglich. Sie bietet zudem eine Art Marktplatz für private und öffentliche Artefakte, die auf der Basis gängiger Virtualisierungs-Anwendungsfälle erstellt wurden. Das ermöglicht einen zügigen Start und den Aufbau einer internen Wissensbasis im eigenen Unternehmen, mit der sich das Erstellen virtueller Services in der Zukunft einfacher gestaltet. Beim Beginn der Nutzung virtueller Services ist es einfach, einen virtuellen Service über Benennungs-Konventionen beziehungsweise durch Beschreibung oder Tagging mit dem ursprünglichen API zu verknüpfen. Die Entwicklungspartner können dann direkt im Web-Browser nach jeglichen virtuellen Assets suchen, die für die zu simulierenden APIs bereits erstellt wurden. Sie sehen dann, welche bereits vorliegen, und können diese umgehend auf ihrem Desktop verwenden. So lassen sich virtuelle Services mit eigenen APIs und Anforderungen verknüpfen.

Kollaboration mit virtuellen Services

Alle soeben skizzierten Lösungen ermöglichen dem Team das Zusammenstellen eines nachhaltigen Arbeitsablaufs. Es kann damit Entwicklern und Testern Alternativen bieten, wenn sie feststellen, dass ein Mock-Objekt benötigt wird. Anstatt Zeit für den Hin-und Rückweg aufzuwenden, können sie das Parasoft-Ökosystem nach einem Mock-Objekt befragen, das ihren spezifischen Anforderungen entspricht. Existiert ein solches, erhalten sie umgehend Zugriff darauf. Ist kein passendes Mock-Objekt vorhanden, können sie einen virtuellen Service erstellen, den auch das Team wiederverwenden kann und der für alle Entwickler auffindbar ist, die es künftig benötigen. Eine elegante Lösung für die Herausforderung der Kollaboration bei Zusammenhängen.

Und dann?

Als kostenlose Version von Parasoft Virtualize bietet die Virtualize Community Edition einen attraktiven Einstieg in die Kollaboration mit der eigenen virtuellen Infrastruktur. Sie enthält alle oben erwähnten Features und ermöglicht den sofortigen Start nach dem Download. Assets lassen sich in Source Control laden, an einen gemeinsamen Team-Server weiterleiten und in den privaten Marktplatz des unternehmenseigenen Teams hochladen. Viel Spaß also beim Virtualisieren!

(jj)