Wer schon einmal einen Webservice entwickelt hat oder nur einen in eine eigene Anwendung einbinden wollte, hat sich sicher schon einmal gewünscht, diesen Webservice ohne viel Aufwand zu testen. Da wir keine uns befriedigende Lösung gefunden haben, schlagen wir in diesem und den folgenden drei Artikeln eine von uns entwickelte Variante vor.

Ziele/Anforderungen

• Keine Beschränkung durch die Quelle des Webservice: Egal ob der Dienst aus .NET, Java oder sonst einer Technologie stammt
• Für Anwender benutzbar - nicht nur für Programmierer
• Keine Programmiererfahrung notwendig
• Keine Programmerstellung oder -kompilierung notwendig
• Keine Beschränkung auf Datentypen in der Schnittstelle - auch Arrays und zusammengesetzte Datentypen müssen funktionieren
• Intuitive Benutzerschnittstelle: Daten für die Parameter der Schnittstelle sollen mit dedizierten Eingabelementen spezifizierbar sein - Beispiel: Kalender zur Eingabe eines Datums

Szenario

Als Test diente ein Webservice, der mit Mono entwickelt und in XSP2 ausgerollt wurde. Die einfachste Version dieses Webservices bestand aus genau einer Operation in der Schnittstelle:

 		[WebMethod]
		public int add(int a, int b)
		{
			return a+b;
		}

Alternativen

XSP2

Die erste Alternative zum Testen eines Webservice ist Mono selbst - beziehungsweise XSP2 : Bei Ausrollen eines solchen Beispielservice wird eine Webseite dafür generiert, auf der es auch ein Testformular gibt. Ein Beispiel für dieses Formular ist für den oben genannten Beispielservice hier dargestellt:

 

Man sieht, daß für jeden Parameter ein entsprechendes Eingabefeld erzeugt wurde und das erwartete Ergebnis angezeigt wird. 

Eine hervorragende Sache also wenn der Service in Mono (.NET) erstellt und in XSP2 augerollt wurde. Da man aber um diese Funktionalität zu benutzen, Zugriff auf den Server haben muß und darüber hinaus dise Methode auf .NET-Webservices beschränkt bleibt, müssen wir uns weiter umsehen.

soapUI

Sucht man im Internet nach "Webservice testen" wird man sofort auf soapUI stoßen. Dieses Werkzeug soll das Testen von Webservices unterstützen. Negativ ist uns aufgefallen, daß das Erstellen eines Projektes extrem lange dauert - dabei ist das WSDL unseres Testservices wirklich übersichtlich. Dazu kam noch, daß es für unsere Tests auf einem lokalen Server lag, so daß auch das Netzwerk nicht schuld gewesen sein kann.

Irgendwann sieht man aber auch mit soapUI die Struktur des Services mit seinen Operationen. Will man eine der Operationen aufrufen, muß man sich mit einer spartanischen Benutzerschnittstelle anfreunden, die wir als für Gelegenheitsnutzer  unbrauchbareinstufen würden - siehe dazu folgenden Screenshot:

Fazit

Unser Fazit - wir brauchen etwas eigenes, das die gestellten Erwartungen erfüllt. Die nächste Folge dieses Artikels wird die grundlegenden Ideen diskutieren, die unserer Lösung zugrunde liegen.