code it

Martins Tech Blog

REST-Services mit SOAPUI testen

Schon in Zeiten von SOAP-Webservices war SOAPUI ein gutes Tool für funktionale Tests der Schnittstelle. Besonders im .NET-Framework, das es dem Entwickler so einfach wie möglich macht, indem Proxies angelegt werden und gleich die große Deserialisierungsmaschinerie anspringt, ist es durchaus an einigen Stellen sinnvoll, überprüfen zu können was genau an Markup über die Leitung geschickt wird und wenn Kommunikation oder Deserialisierung fehlschlagen.

Auch bei rest-basierten Services kann das an vielen Stellen sinnvoll sein. In meinem aktuellen Beispiel verwende ich einen REST-Service eines Drittanbieters von einem Android-Phone aus. Leider ist der Service des Anbieters noch in der Entwicklung und die Schnittstelle ändert sich gelegentlich. In meinem Fall gab es ein Serialisierungsproblem auf Anbieterseite - so wurden Objekte an einem Endpunkt, der eine Liste zurückgeben sollte nicht immer als Objektliste serialisiert, was dann natürlich bei der Deserialisierung zu argen Problemen führt. Dafür habe ich mir mit SOAPUI einen Test geschrieben.

Gehen wir von folgendem Szenario aus: Es gibt einen Endpunkt, der JSON zurückgibt. Laut Schnittstellen-Definition handelt es sich dabei um eine Liste von Personendaten. Leider ist es bei der Implementierung zu einem Fehler gekommen so dass nicht immer eine Liste zurückgegeben wird. Ein entsprechendes fehlerhaftes Beispiel ist in .NET schnell erstellt.
public class SampleController : Controller
{
    public JsonResult GetAll()
    {
        var persons = new PersonRepository().GetAll();
        if (persons.Count == 1)
        {
            return this.Json(persons[0], JsonRequestBehavior.AllowGet);
        }

        return this.Json(persons, JsonRequestBehavior.AllowGet);
    }
}

Nun zum eigentlichen Punkt - der Test. Ein Projekt in SOAPUI ist schnell erstellt.

Basierend auf diesem Request kann nun mit Hilfe des entsprechenden Kontextmenü-Eintrags ein neuer Test erzeugt werden.


Nun müssen nur noch Assertations festgelegt werden. Das kann im entsprechenden Tab erledigt werden.
Meine erste Assertation ist, dass Statuscode 200 zurückkommt.

Basierend auf den Eingabeparametern (die es in meinem Beispiel nicht gibt) könnte man auch auf andere Statuscodes prüfen - z.B. 401 (Unauthorized) oder 409 (Conflict) usw.

Prüfung 2 ist, ob wir eine Liste zurückbekommen, die den Anforderungen entspricht. Das macht man am besten scriptgesteuert. SOAPUI greift dazu auf Groovy-Scripte zurück:

Ein Script könnte so aussehen:
import groovy.json.JsonSlurper 

def response = messageExchange.response.responseContent
def slurper = new JsonSlurper()
def json = slurper.parseText response

List persons = (List) json;
assert !(persons.isEmpty())
persons.each{
	assert it.LastName != null
	assert it.FirstName != null
}
So kann man nun feststellen, ob das Ergebnis stimmt oder eben nicht. Bekomme ich statt der erwarteten Liste nur ein Objekt zurück, schlägt hier der Cast fehl.

Diese Tests kann man nun einzeln oder im Kommandozeilen-Testrunner ausführen und so automatisiert feststellen, ob das Backend tut was es tun soll.

Array-Parameter im WCF Test-Client

Zugegeben, die Eingabe von Array-Parametern im WCF-Test-Client ist nicht sehr intuitiv. Und eben weil man es auf den ersten Blick nicht erkennt, hier an dieser Stelle ein kleiner Tipp für alle die schon daran gescheitert sind.

Gegeben ist ein WCF-Service, der einen Array-Parameter hat - in meinem Beispiel gibt es den EmployeeService, welcher in der Methode Create eine Auflistung an Objekten vom Typ Employee entgegennimmt.

[ServiceContract]
public interface IEmployeeService
{
    [OperationContract]
    void Create(IEnumerable<Employee> employees);
}

Soweit nicht weiter kompliziert.

Startet man im Visual Studio nun eine neue Instanz des Services, so öffnet sich der WCF Test-Client und man kann den Service aufrufen, wenn man es denn schafft, hier Objekte vom Typ Employee einzutragen. Mehr...