Funktioniert unsere ERP Schnittstelle? Automatisiertes Testing mit OxERPTest

Eigentlich sollte das funktionieren…

Das ist eine der häufigsten Antworten eines Entwicklers auf die Frage: ”Funktioniert unsere ERP Schnittstelle?”.

Aber warum ist das so? Warum können wir nur so schwer sagen ob unsere Schnittstelle funktioniert oder nicht und wie können wir das ändern? Schließlich handelt es sich hierbei ja nicht um ein Bild was „mal“ nicht angezeigt wird oder um einen Rechtschreibfehler in der Produktbeschreibung. Es handelt sich in den meisten Projekten um den wahrscheinlich einzigen Kommunikationsweg über den wir Produktinformationen in den Shop und Bestellungen aus dem Shop bekommen. Darum sollten wir doch gerade hier zu 100% Gewissheit haben, dass alles so funktioniert wie wir es erwarten.

Weiterhin ist es ja mit den ERP-Basisfunktionen heutzutage nicht mehr getan. Viele Kunden haben speziell auf ihre Bedürfnisse angepasste Warenwirtschaftssysteme und/oder  Middleware Produkte die den Einsatz von ERP-Plugins notwendig machen. Wie stellen wir also sicher dass, das von uns entwickelte Plugin nicht andere Funktionen der ERP beeinflusst?

Diese Fragen stellte ich mir nachdem ich das letzte mal so eine qualifizierte „eigentlich sollte“-Antwort auf die o.g. Eingangsfrage gegeben hatte. Die Antworten darauf sind vergleichsweise simpel. Wir kennen die Requests, wir kennen die Responses und wir haben einen User der Zugriff auf die ERP hat. Packen wir das alles zusammen in ein Symfony2 CLI Kommando, haben wir alles was wir für ein automatisiertes Testing Tool brauchen. So entstand OxERPTest und nach knapp einem Wochenende hatte ich die Idee wie man ein Symfony2 CLI Kommando für diesen Zweck nutzen könnte umgesetzt, getestet und auf GitHub veröffentlicht.

OxERPTest

ist ein kleines aber effizientes Kommandozeilen Tool welches sich problemlos in bestehende Testszenarien einbinden lässt, bspw. in eine Jenkins Build Pipeline. Das Prinzip ist einfach, das Tool authentifiziert sich erst mittels eines privilegierten Users an der OXID ERP und sendet dann vorgegebene XML-Calls an diese. Kommt von der ERP ein Response zurück, wird dieser entgegen genommen und mit einem zuvor angelegten Referenzwert vergleichen. Stimmen beide Responses überein, haben wir einen Match und wissen, dass die ERP sich so verhält wie wir es erwarten.

Im Detail sieht das ganze dann wie folgt aus. Nehmen wir an wir möchten sicherstellen, dass der Abholprozess einer Bestellung gewährleistet ist. Dazu legen wir eine XML Datei mit dem Namen OXERPGetOrder.xml unterhalb des Repositroy-Roots in var/calls/ ab und fügen hier den zu sendenden ERP-Call ein. Da die Session ID des Calls jedes mal neu generiert wird, muss diese im Call mit einem Platzhalter versehen werden (##SESSIONID##) damit OxERPTest diese zur laufzeit ersetzen kann.

Danach legen wir den Response unterhalb von var/responses/ ab und benennen diesen wie den Call zzgl. des Zusatzes „Response“. Sprich aus OXERPGetOrder.xml wird OXERPGetOrderResponse.xml. In dieser Datei legen wir den RAW Response ab den wir von der ERP erwarten. Diesen können wir bspw. mittels curl erstellen oder aus unserem ERP-Log in Warenwirtschaft oder Middleware beziehen.

Danach können wir das Programm starten. Wir haben die Möglichkeit alle oder einen separaten Call zu testen. 

Zudem können wir das Defaultverhalten mittels optionaler Übergabewerte beeinflussen.

Die möglichen Status der OxERPTest Calls sind:

  • „test passed“ (success) im Erfolgsfall
  • „call ok, but content compare faild“ (note) hier konnte zwar der Call erfolgreich abgesendet werden aber der Response entspricht nicht dem erwarteten Ergebnis
  • „test faild with exception“ (warning) ein Fehler im Testprozess ist aufgetrten bspl. es konnte keine Authentifizierung stattfinden.

OxERPTest an sich kann, da es sich um ein Symfony2 Konsolenkommando handelt, nur den Status „0“ oder „1“ zurückliefen. Z.B. wird beendet sich das Programm mit dem return Value „1“ wenn es gestartet wird, aber keine Calls und Responses definiert sind. Wird „0“ zurückgegeben konnte das Programm erfolgreich beendet werden.

Fazit

Somit sind wir nun in der Lage jederzeit die erwartete Funktion der ERP in kürzester Zeit sicherzustellen und die Frage “Funktioniert unsere ERP Schnittstelle?” mit einem klaren “Ja” zu beantworten.

Detaillierte Bespiele, die README, Dummy-Calls und OxERPTest an sich findet Ihr hier: https://github.com/patrick-blom/oxerptest .

Feedback, PullRequest und Bugfixes sind sind selbstverständlich erwünscht.


0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *