Allgemein ·Clean Code ·Entwicklung ·Fiori

Testing in SAPUI5 Teil 1 – Mock Server zum Testen von Fiori Apps

Wer kennt es nicht, man baut eine App und möchte sie testen, aber es sind keine Daten vorhanden. Das kann mehrere Gründe haben: der OData Service ist nicht erreichbar, es gibt (noch) keinen Zugriff auf den Service oder das Entwicklungssystem ist schlicht leer.

Das Zauberwort für die Lösung dieses Problems heißt Mock Server.

Das Prinzip des Mock Servers ist ganz einfach. Wenn aus der App das Backend aufgerufen wird, wird dieser Call vom Mock Server abgefangen. Dieser simuliert dann ein Backend System und zeigt uns dafür lokale Daten an. Diese Daten können entweder aus unserem bestehenden Service stammen oder von der Web IDE zufällig erzeugt werden. Will man sich ganz spezielle Daten anzeigen lassen, können diese natürlich auch manuell eingeben werden.

Erstellen des Mock Servers mit Hilfe von Web IDE Templates

Wird eine SAPUI5 App auf Basis der Web IDE Templates für Worklist oder MasterDetail erzeugt, ist bereits ein Ordner “localService” mit den Dateien metadata.xml und mockserver.js vorhanden. Zudem wurde im Ordner “test” eine Datei flpSandboxMockServer.html erzeugt. Diese ähnelt der index.html und dient dazu, die App im “Testmodus”, also mit den Mock Daten zu starten.

Nun fehlen nur noch die Daten. Diese lassen sich ganz einfach aus dem eigenen Service erstellen, indem wir den Service mit dem URL-Parameter ?$format=json aufrufen.

Anzeigen des Services im JSON-Format

Alternativ kann auch die Web IDE Zufallsdaten auf Basis der metadata.xml erzeugen.

Dazu klickt man mit der rechten Maustaste auf die metadata.xml im localService Ordner seiner App und im sich öffnenden Kontextmenü auf “Edit Mock Data”. Daraufhin öffnet sich ein Dialog mit allen in der metadata.xml beschriebenen Entitäten. Durch einen Klick auf “Generate Random Data” lassen sich ganz einfach Daten für die ausgewählte Entität erzeugen.

Assistent zum Bearbeiten der Mock Daten

Außerdem haben wir hier die Möglichkeit, einzelne Zeilen manuell hinzuzufügen oder zu löschen.

Datensätze löschen oder hinzufügen

Nach einem Klick auf “OK” findet sich im localService Ordner ein neuer Ordner “mockdata”, in dem für jede Entität für die man Daten erzeugt hat, eine entsprechende .js Datei vorhanden ist.

Erstellen des Mock Servers ohne Web IDE Templates

Nutzt man die Templates der Web IDE nicht, müssen diese Dateien selbst erzeugt werden. Dazu sind folgende Schritte notwendig:

Die Datei mockServer.html oder auch flpSandboxMockServer.html falls die App in einer Launchpad Sandbox gestartet werden soll, sollte im Ordner test angelegt werden.

In dieser Datei fügen wir den Code der index.html ein und ergänzen die attachInit Funktion folgendermaßen:

sap.ui.getCore().attachInit(function () {
        // load mockserver.js as required file
	sap.ui.require([
                // change the path to your own mockserver.js!
		"my/mockserverBlog/localService/mockserver"   
	], function (mockserver) {
		// set up test service for local testing
		mockserver.init();
                // initialize the shell
                [...]
	});
});

Die metadata.xml und die json-Dateien mit den Fakedaten lassen sich wie anfangs beschrieben am einfachsten aus dem eigenen Service erzeugen.

Für die mockserver.js kann man folgendes Beispielcoding kopieren. Danach müssen nur noch die Pfade (hier my/mockserverBlock/…) angepasst werden.

sap.ui.define([
	"sap/ui/core/util/MockServer"
], function (MockServer) {
	"use strict";
	return {
		init: function () {
			var sManifestUrl = jQuery.sap.getModulePath("my/mockserverBlog/manifest", ".json"),
			sJsonFilesUrl = jQuery.sap.getModulePath("my/mockserverBlog/localService/mockdata"),
			oManifest = jQuery.sap.syncGetJSON(sManifestUrl).data,
			oMainDataSource = oManifest["sap.app"].dataSources.mainService,
			sMetadataUrl = jQuery.sap.getModulePath("my/mockserverBlog/" + oMainDataSource.settings.localUri.replace(".xml", ""), ".xml"),
			// ensure there is a trailing slash
			sMockServerUrl = /.*\/$/.test(oMainDataSource.uri) ? oMainDataSource.uri : oMainDataSource.uri + "/";
			// create
			var oMockServer = new MockServer({
				rootUri: sMockServerUrl
			}); 
			var oUriParameters = jQuery.sap.getUriParameters();
			// configure
			MockServer.config({
				autoRespond: true,
				autoRespondAfter: oUriParameters.get("serverDelay") || 1000
			});
			// simulate
			oMockServer.simulate(sMetadataUrl, sJsonFilesUrl);
			// start
			oMockServer.start();
		}
	};
});

Die von der Web IDE beim erstellen einer App aus einem Template erzeugte mockserver.js ist etwas größer und beinhaltet unter anderem noch Fehlerbehandlung für das Laden der Mockdaten.

Aus Übersichtsgründen habe ich in eine abgespeckte Variante vorgestellt. Wer interessiert ist kann sich ganz einfach eine Testapp mit dem Worklist oder Master-Detail Template erstellen und sich den von der Web IDE generierten Code anschauen bzw. in sein eigenes Projekt kopieren und anpassen.

Am Ende sollte das Projekt folgende Ordner und Dateien enthalten (der Inhalt des Ordners “mockdata” hängt von dem eigenen Service ab).

Alle angelegten Dateien und Ordner

Viele denken jetzt vielleicht, “das ist ja zusätzliche Arbeit”, “wieso sollte ich mir das antun, mein Service ist sowieso verfügbar und falls nicht, warte ich einfach bis er wieder verfügbar ist”.

Das mag in manchen Situationen vielleicht zutreffen, das Problem eines Entwicklungssystems ohne (Test-)Daten löst es dennoch nicht.

Zudem hat die Nutzung von Mock Daten noch einen weiteren Vorteil, Stichwort Testing.
Wer möchte schon, dass seine Unit-Tests fehlschlagen, weil der Service kurzzeitig nicht erreichbar war? Im schlimmsten Fall sucht man nach einem Fehler den es gar nicht gibt, bevor auffällt, dass der Service die Ursache war.
Auch machen es Mock Daten einfacher, Tests zu schreiben. Da diese Daten sich im allgemeinen nicht ändern, können in der Testimplementierung ohne Bedenken statische IDs, Namen oder Zahlen verwendet werden.

Schon gesehen?
Arbeiten als SAPUI5-Entwickler bei Acando

Schreibe einen Kommentar