Wie schon ein paar mal geschrieben, bin ich schwer begeistert wie einfach es mit angularJS ist, Web Apps mit Javascript zu entwickeln. Vielleicht merkt man das auch an der ein oder anderen Stelle 🙂

Aber egal, wie einfach das Entwickeln ist, wir machen alle Fehler. Deshalb muss auch angularJS-Code getestet werden, mindestens Unit-Tests besser noch mit End-2-End-Tests.

[highlight1]Aber moment mal, Javascript-Code und Unit-Tests? Geht das überhaupt? [/highlight1]

Aber klar! Schon lang gibt es diverse Test-Frameworks für Javascript. jQuery benutzt z.B. qunit, die AngularJS-Entwickler bevorzugen Jasmine.

Als Skriptsprache, die beim Kunden im Browser ausgeführt wird, ist es bei Javascript-Tests natürlich wichtig, sie dort auszuführen wo sie laufen: im Browser. Und das ist ohne spezialisierte Tools äußerst aufwändig.

Als sogenannter Test Runner, gibt es seit einigen Jahren jsTestDriver (von Google), das Unit-Tests entgegennimmt und dafür sorgt, sie auf angeschlossenen Browsern auszuführen. Leider habe ich keine gute Erfahrung damit gemacht, da es allgemein recht instabil läuft, mehrfach täglich neugestartet werden muss und nach Neustart das automatische Wiederverbinden mit den Browsern eher hakelig ist. Außerdem scheint die Weiterentwicklung auch eher eingeschlafen zu sein.

Die AngularJS-Entwickler haben sich deshalb entschlossen, einen eigenen Test Runner zu entwickeln. [highlight1]Testacular[/highlight1].

Testacular ist kein Testframework, sondern wirklich nur der Test Runner. Man schreibt die Unit-Tests also z.B. als Jasmine-Tests und führt sie mit Testacular in Chrome oder Firefox oder Safari oder auch in PhantomJS (Headless Browser) aus.

Da wir AngularJS u.a. auch mit requireJS benutzen, ist es allerdings nicht ganz einfach, als Anfänger zu verstehen, wie man Testacular konfigurieren muss, damit requireJS den Produktions- und Testcode asynchron nachladen kann und erst danach Testacular loslegt um die Tests auszuführen.

Standardmässig liefert Testacular nämlich eine Webseite an den Browser aus, in der alle referenzierten *.js-Dateien automatisch als <script>-Tag referenziert werden, damit der Browser sie lädt. Nach Laden der Seite fängt dann Testacular an, die Tests auszuführen. Mit requireJS darf Testacular allerdings die Skripte eben gerade nicht mittels <script>-Tag laden, sondern dies übernimmt require.js. Nur die main.js um requireJS zu laden und zu konfigurieren, darf so eingebunden werden.

Als Startpunkt für meine Konfiguration mit requireJS habe ich einen Artikel bei Jake Trent gefunden, der sich genau diesem Problem widmet. Im Gegensatz zu diesem Artikel kann ich aber sagen, dass die komplette requireJS-Konfiguration wie man sie im Produktionsbetrieb gewohnt ist, auch für Testacular funktioniert. Testacular bindet mit meiner Konfiguration nur noch Jasmine, requireJS und die main-test.js ein. Alles andere lädt requireJS nach.

Dies erreicht man mit folgender Konfiguration der Dateien:

files = [
	JASMINE,
	JASMINE_ADAPTER,
	REQUIRE,
	REQUIRE_ADAPTER,
	{pattern:'src/main/external-libs/angular-1.0.3.js', included:false},
	{pattern:'src/test/external-libs/angular-mocks-1.0.3.js', included:false},
	{pattern:'src/main/js/**/*', included:false}, //Produktionscode
	{pattern:'src/test/unit/**/*.js', included:false}, //Testcode
	'src/test/main-test.js' //requireJS-Konfiguration
];

Entscheidend ist hier das [hightlight1]included:false[/highlight], was dafür sorgt, dass die Dateien zwar verfügbar sind, aber nicht per <script> automatisch ausgeliefert werden. Der Rest der Konfiguration kann so aus dem verlinkten Artikel übernommen werden.

In der main-test.js Datei muss man nun dafür sorgen, dass die eigene Anwendung geladen wird (die ja sowieso schon aus require-Module bestehen sollte), die Testklassen geladen werden (das müssen nun auch alles require-Module sein, siehe Artikel) und wenn das alles geladen ist, muss Testacular mitgeteilt werden, dass es nun loslegen kann. Meine main-test.js sieht wie folgt aus:

(function (window, require) {
	"use strict";
	var file, requireModules;
	requireModules = [];

	//aus den von Testaular bereitgestellten Dateien alle *Test-Dateien raussuchen und Pfad anpassen, damit requireJS
	//was damit anfangen kann
	for (file in window.__testacular__.files) {
		if (window.__testacular__.files.hasOwnProperty(file)) {
			if (file.substring(file.length - 7, file.length) === 'Test.js') {
				requireModules.push("../.." + file.substring(9, file.length - 3));
			}
		}
	}

	// unsere eigene Anwendung inkl. Abhängigkeiten laden
	requireModules.push("app");

	//angular Mocks laden
	requireModules.push("mocks");

	require({
		// "/base" ist die URL von der Testacular alle Dateien ausliefert,
		// "src/main/js" ist due Base-URL aller Module die nicht Test sind
		baseUrl:'/base/src/main/js',
		paths:{
			'angular':'../external-libs/angular-1.0.3',
			'mocks':'../../test/external-libs/angular-mocks-1.0.3'
		},
		shim:{
			'angular':{ exports:'angular' },
			'mocks':{ deps:['angular'], exports:'mocks' }
		}
	}, requireModules, function () {
		//erst hier wird Testacular tatsächlich (manuell) gestartet
		window.__testacular__.start();
	}, function (err) {
		//hier kommt die Fehlerbehandlung hin
	});
}(window, require));

Über den Zugriff auf [highlight1]window.__testacular__.files[/highlight1] hole ich mir alle Testdateien und bastele daraus die korrekt benamten require-Module. Dann wird noch die eigentliche Anwendung und Angular hinzugefügt. Wenn requireJS alles geladen hat, wird dann über [highlight1]window.__testacular__.start();[/highlight1] Testacular gestartet.

Wenn man das einmal begriffen hat, ist es eigentlich recht einfach. Aber das ist ja häufig so 🙂 Testacular ohne requireJS zu konfigurieren, ist auch deutlich einfacher.

Wenn es dann einmal läuft, hat man aber einen hervorragenden Testrunner, den man dann auch in Webstorm (Javascript IDE) integrieren kann, um direkt in der IDE, die Unit Tests starten zu können und – besonders beeindruckend – auch direkt in der IDE debuggen kann.

Aber dazu ein anderes mal mehr Details.

Momentan bin ich recht begeistert von AngularJS, THE next best thing in der Javascript-Entwicklung. Meine nächsten Artikel werden sich wohl hauptsächlich um die Entwicklung mit diesem MVC-Framework von Google drehen.

Pascal Precht hat eine hervorragende Slideshow über AngularJS erstellt. Mit und in AngularJS. Aber seht selbst:

AngularJS Insights

sinopsis film

angularJS ist großartig und macht Spaß. Je mehr Code ich damit entwickle, umso begeisterter bin ich.

Um auch in unserer Web App einen zentralen Platz für unsere Lokalisierungen zu haben, habe ich einen Service geschrieben, der sich zentral um die Lokalisierung von allen Texten kümmern soll. Als Java-Entwickler wollte ich etwas ähnliches entwickeln, wie ResourceBundles und Properties-Dateien.

Meine Lösung ist als Angular-Service implementiert und die Lokalisierungstexte sind in JSON-Dateien ausgelagert. Der Service lädt die passende JSON-Datei asynchron per [highlight1]$http-Service[/highlight1] nach und stellt die Texte systemweit über eine [highlight1]localizationService.translate()[/highlight1]-Methode zur Verfügung. Die Lokalisierungsstrings lassen sich den Java-Properties parametrisieren, wobei die aktuelle Implementierung nur einen Parameter auswertet, weil wir aktuell nur einen benötigen. Die Formatierung greift dabei auf eine format-Methode am String-Prototyp zurück.

Hinweis: der Code um die Browsersprache zu erkennen fehlt, damit der Code einfacher zu verstehen ist.

	function localizationServiceFactory($http, $q) {
		var translationsDE, errorMessage;

		function loadTranslations() {
			var deferred = $q.defer();

			if (!translationsDE) {
				$http.get("/json/translations/translationsDE.json").then(
					function(data) {
						translationsDE = data;
						errorMessage = '';
						deferred.resolve();
					},
					function(error) {
						translationsDE = {};
						errorMessage = error;
					}
				);
			} else {
				deferred.resolve();
			}

			return deferred.promise;
		}

		function translate(key, param) {
			var translation = "";

			return loadTranslations().then(function() {
				if (key) {
					translation = translationsDE[key];

					//unbekannter Key = gib Key zurück
					if(!translation) {
						translation = key;
					}

					if (param) {
						translation = translation.format(param);
					}
				}

				return translation;
			});
		}

		return {
			translate:translate
		};
	}

	localizationServiceFactory.$inject = ['backendService', '$q'];
	angularModule.factory("localizationService", localizationServiceFactory);

{
	"MEIN_STRING": "Das ist die Lokalisierung",
	"NOCH_EIN_STRING": "Und noch eine",
	"FALSCHER_BENUTZER": "Benutzername {0} wurde nicht gefunden."
}

//format Methode, {0} {1} usw.
if (!String.prototype.hasOwnProperty("format")) {
	String.prototype.format = function() {
		var formatted, i, regexp;
		formatted = this;
		for (i = 0; i < arguments.length; i++) {
			regexp = new RegExp('\\{'+i+'\\}', 'gi');
			formatted = formatted.replace(regexp, arguments[i]);
		}
		return formatted;
	};
}

Das wirklich schöne an dem Service ist, dass er die JSON-Datei asynchron nachlädt, wenn sie gebraucht wird. Wenn man den Code zur Spracherkennung entsprechend baut, lädt er auch nur die tatsächlich benötigte Lokalisierung. Nicht benötigte Lokalisierungen landen erst gar nicht im Browser.

Was mich am meisten beeindruckt hat, ist der Umgang von AngularJS mit dem [highlight1]Promise-Objekt[/highlight1] das die translate-Methode in jedem Fall zurückgibt. In diesem Fall sorgt angularJS nämlich automatisch dafür, dass die Aufrufe von translate aus einem Controller heraus synchron aufgelöst werden, sodass man im Controller ohne besonderes Zutun auf jeden Fall einen lokalisierten String bekommt, obwohl der $http-Request asynchron abläuft und zum Zeitpunkt des Aufrufes eventuell noch gar nicht abgeschlossen ist.

Man könnte es fast als Magie bezeichnen 🙂

Momentan beschäftige ich mich erstmals mit einer reinen Javascript Web App, die komplett aus statischen HTML- und JS-Dateien besteht und über eine REST-Schnittstelle mit (dynamischen) Daten versorgt wird. Als Technologien verwende ich dabei so interessante Sachen, wie [highlight1]angularJS[/highlight1], [highlight1]jQuery Mobile[/highlight1] und [highlight1]Jasmine[/highlight1]. Alles super spannend.

Aber wie verwaltet man so eine App im professionellen Einsatz, wenn man an Maven als Build-, Dependency Management- und Deployment-Tool gewohnt ist? Und im Jenkins (Continous Integration) soll es natürlich ebenfalls integrierbar sein. Und regelmässige Unit-Tests sollen auch ausgeführt werden. Und automatisch verteilte Builds, die ins automatische Deployment einlaufen.

Einfach mal die HTML- und JS-Dateien manuell ins Apache-Verzeichnis zu kopieren, kommt jedenfalls nicht in Frage.

Continue reading grunt – Ein Javascript Build Tool →