Ich beschäftige mich gerade mit dem Thema SoapUI und dessen Integrationsmöglichkeiten.  Selbstverständlich, muss man aber auch im ganzen erstmal definieren was und wie man in einer API testen möchte.

Wie man eine API testet?

Diese Fragen behandeln ein How to zum Thema “Testen einer API” und definiert entscheidende Fragen, wie wir uns den Test einer API aufbauen können. Diese Fragen sind für eine Konzeption innerhalb eines Textkonzeptes von Nöten.

In einem Stackoverflow Beitrag  an dem ich beteiligt gewesen bin, haben wir folgende Fragen herauskristallisiert. Und sollte jedem eine hilfreich Stütze sein, um seinen API Test entsprechend zu planen. 

Generally

Test the API Endpoints, Status Codes and Data

Specifically

  • What documentation exists ?
  • What functionality it provide ?
  • Does it support concurrency ?
  • What are the API endpoints ?
  • Is the API internal or external ?
  • Which endpoints are idempotent ?
  • Are endpoints stateless or stateful ?
  • Do any workflows*1 vary by client ?
  • Are there performance requirements ?
  • Do API endpoints make up a workflow ?
  • What validations are expected for data ?
  • What system or library is behind the API ?
  • Do we need to mock dependent services ?
  • Does it constrain traffic aka Rate Limiting ?
  • What (if any) versioning approach is used ?
  • Does the API support Multiple Languages ?
  • If already using SOAPui, how is it integrated ?
  • Is the API be restricted to a country or region ?
  • Does it provide client stubs in specific languages ?
  • Are there existing API definitions e.g. WADL, WSDL, Thrift definitions (if applicable) ?
  • What status codes are expected for given endpoints ?
  • What domain format and structure exists for the data ?
  • Does the API use HATEOS*2 for self documentation ?
  • What kind of data validation/ testing can be performed ?
  • What API is supported by the test framework I’m using ?
  • What actions are performed, e.g. GET, PUT, POST etc ?
  • Do we need to prepare dependent test data or services ?
  • What non-API approaches will be needed to verify data ?
  • What non-API approaches will be needed to prepare data ?
  • What (if any) Authorization (‘what’) mechanism will be used ?
  • What (if any) Authentication (‘who’) mechanism will be used ?
  • What format(s): SOAP, REST, GraphQL, Thrift, ProtoBuffer, Other ?
  • Who will use it, external programmers or another internal module ?

*1 Workflows often require multiple API calls and may have dependencies between them
*2 HATEOS – Hypertext As The Engine Of Application State, which allows self-discovery of an API

Im einzelnen wäre also zu klären, was getestet werden sollte. Liegen alle Unterlagen vor? Habt ihr einen Plan und zwar einen Testplan?

Bevor ihr also euch darüber Gedanken machen solltet, welche Tools ihr zum API testen nutzen wollt, solltet ihr klären ob ihr einen Plan habt wie ihr die API testen wollt. 

Es gibt dazu sehr interessante Hinweise und Artikel die zu diesem Thema eventuell noch weiterführende Informationen anbieten.

Test Integrationen

RestAPIs zu automatisieren ist immer ein Thema welches vielschichtig ist. Man kann über unterschiedliche Lösungen nachdenken, zum einen über API Gateway Lösungen oder eben über andere Integrationsmöglichkeiten in schon bestehende Prozess. 

Eine gute Lösung ist hier auch immer der Ansatz über eine Jenkins Pipeline. Dazu aber im Einzelnen im weiteren Verlauf des Textes.

SoapUI Test mit Cucumber integrieren

Eine interessante Möglichkeit der Integration von agilen Prozessen ist SoapUI mit Cucumber zu integrieren. Eine gute Anleitung dazu findet man auf den Seiten von Smartbear selbst: ReadyAPI ( Soapui) Integration with Selenium/ Cucumber

Auf Seiten von SmartBear findet man entsprechend auch eine längere Anleitung zu diesem Thema: https://support.smartbear.com/loadcomplete/docs/working-with/integration/cucumber.html

 

Testen eines Webservice mit SoapUI, JUnit, Maven und Cucumber. Ein sehr interessanter Ansatz den ich hier entsprechend mal aufbereite.

 

BDD Integration with Citrus & Cucumber

SoapUI kann auch an BDD angebunden werden. Dazu nutzen wird

Automatisierte Integrationstests für Nachrichtenprotokolle und Datenformate!
HTTP REST, JMS, TCP/IP, SOAP, FTP, SSH, XML, JSON und mehr!

http://citrusframework.org/ 

Testmanagement 

SoapUI + Jira 

SoapUi bietet viele Integrationsmöglichkeiten, nicht nur im Bereich der Testautomatisierung sondern eben auch im Bereich Test Management. Die meisten Fragen die ich u.a. immer gestellt bekomme zu diesem Thema, kann ich Jira und Confluence + SoapUi in bestehende Prozesse einbinden? 

Absolut, SmartBear bietet dafür sogar ein eigenes Plugin an.

https://github.com/SmartBear/ready-jira-plugin/wiki/About-the-JIRA-Integration-Plugin

Weitere Integrationsmöglichkeiten findet man als Informationen auch auf Seiten von SmartBear: 

https://support.smartbear.com/readyapi/docs/integrations/jira.html