javablog.ch

Im Gegensatz zu Mocktests beschränkt sich ein Integrationstest nicht auf die JVM, sondern involviert auch Fremdsysteme wie Datenbanken, LDAPs oder Webservices. Ein Integrationstest ist auf immer gleichbleibende Testdaten im Fremdsystem angewiesen, muss aber ggf. auch den schreibenden Zugriff testen. Hier bieten sich Transaktionen an: Jede Testmethode läuft in einer eigenen Transaktion, die unabhängig vom Testergebnis immer wieder zurückgerollt wird. Somit bleibt das Fremdsystem in einem definierten Zustand. Dennoch sollten Integrationstests nicht auf den späteren Liveinstanzen ausgeführt werden, sondern immer auf dedizierte Testinstanzen. Allerdings sollte sichergestellt sein, dass die Test- und Liveinstanzen sich gleich verhalten.

Integrationstests bieten sich insbesondere für Dao-Klassen an, da hier der Zugriffscode für Fremdsysteme gekapselt wird. Gute Unterstützung bietet hier das Spring Framework mit den Annotationen @RunWith, @Transactional und @TransactionalConfiguration.

Beispiel-Code:

Vorteile:

• Das konkrete Verhalten eines Fremdsystems (z.B. Active Directory, oder einer MSSQL) kann abgeprüft werden.
• Fremde Webservices können automatisiert auf ihre Konsistenz geprüft werden.

Mögliche Stolperfallen:

• Integrationstests laufen nicht offline. Bei Mavenprojekten sollten sie für die Offline-Entwicklung abgeschaltet werden, da sonst der Build scheitert. Dies kann durch ein eigenes “mobile”-Profil in Kombination mit dem maven-sunfire-plugin sichergestellt werden.
• Die Testausführung dauert bei Integrationstest im Vergleich zu “normalen” JUnit-Tests wesentlich länger. Bei steigender Anzahl von länger laufenden Tests ist ein kompletter Durchlauf der Tests auf den Entwicklungsmaschinen nicht mehr sinnvoll.

Fantastisch: Das “eStore”-Projekt, an dem ich letztes Jahr in allen Projektphasen mitarbeiten durfte, wurde nun für den “Master of Swiss Web Award 2009″ nominiert.

Der nominierte eStore setzt auf der java-basierten Hybris PIM (Product Information Management) Platform auf, in der die Produktdaten aus mehreren Systemen (SAP, iPFG, Celum) zusammengefasst werden. Das Frontend haben wir mit Spring MVC umgesetzt. Viel Arbeit steckte auch in der Entwicklung des Carts und dem anschliessenden Bestellprozess. Zum Projekt gehörte ebenfalls das Aufsetzen der Infrastruktur: Vom Microsoft ISA 2006 als Webproxy bis hin zum eigenen Active Directory für die Kundenlogins war alles dabei.

Sowohl aus technischer als auch aus fachlicher Sicht ein absolut spannendes Projekt. An der Stelle ein dickes Dankeschön an alle Beteiligten !

Ach ja: Wer für unser Projekt abstimmen möchte muss sich erst hier registrieren.

Update 05.04.2009: Leider hats nicht zum Master gereicht. Allerdings können wir uns über Silber in der Kategorie Technology Quality und Bronze in der Kategorie Usability freuen.

Diese neue Artikelserie stellt Variaten von Unit-Tests vor und geht auf die jeweiligen Eigenschaften und Einsatzzwecke ein. Im ersten Teil werden Mock-Tests vorgestellt.

In Mock-Tests wird die Interaktion des zu testenden Objekts mit einem Mock-Objekt geprüft. Konkret werden sogenannte Erwartungen definiert, die das zu testende Objekt in Form von Methodenaufrufen erfüllen muss. Das eigentliche Mock-Objekt wird zur Laufzeit durch Frameworks wie jMock oder EasyMock generiert, eine eigene Implementierung des Interfaces ist dazu nicht notwendig.

Beispiel:
Eine Service-Klasse besitzt zwei Dao (“Data Access Object”) Objekte, die den Zugriff auf eine Datenbank kapseln. Beide Dao-Klassen wurden bereits mit separaten Unit-Tests abgeprüft, nun möchten wir die Service-Klasse selbst testen (ohne dabei die Dao-Klassen nochmals zu testen). Hier greifen wir auf ein Mock-Framework zurück und testen die Service-Klasse mit Mock-Versionen ihrer Daos. Für jede Methode unserer Service-Klasse beschreiben wir nun, welche Dao-Methoden aufgerufen werden sollten (und was sie in diesem Fall zurückgeben sollen).

Vorteile:

• Mock-Tests erlauben losgelöstes Testen und bringen den Entwickler dazu, sich intensiver mit der Interaktion seiner Objekte zu beschäftigen.
• Es werden keine Klassen doppelt getestet.
• Service-Klassen können ohne Abhängigkeit zu Fremdsystemen getestet werden.

Mögliche Stolperfallen:

• Ein Mock-Test bindet sich stark an die Implementierung. Wenn es alternative Wege zur Zielerreichung gibt (z.B. überladene Methoden), dann scheitert der Test, obwohl das Resultat des Methodenaufrufs weiterhin richtig wäre.
• Das Mocken von fremden Klassen führt zu falschen Annahmen, da der Entwickler oftmals das genaue Verhalten eines Frameworks nicht immer zu 100% nachbilden kann.
• Die Erwartungen (sog. Expectations) der Mock-Tests werden zu komplex (Perl-Syndrom: write once – never understand again.)

Empfohlene Artikel zum Vertiefen:

• Mocks Aren’t Stubs
• Only mock types you own

Die namespace-Konfiguration legt einen eigenen AuthenticationManager an, der sich nicht über die XML-Konfiguration austauschen lässt:

You can’t use a custom AuthenticationProvider if you are using either HTTP or method security through the namespace, but this should not be a problem as you have full control over the AuthenticationProviders that are used.

http://static.springframework.org/spring-security/site/reference/html/ns-config.html (Kapitel 2.6).

Es gibt aber Situationen, wo man genau dies möchte. Beispielsweise im Osgi-Umfeld: In einem Bundle wird ein AuthenticationManager deklariert, der von anderen Web Bundles wiederverwendet werden soll.

Der Trick (bzw. der Hack) ist, dass die BeanId des AuthenticationManager genau “_authenticationManager” heissen muss. Wenn eine solche Bean existiert, dann verwendet die namespace-Konfiguration genau diesen AuthenticationManager statt einen eigenen zu erzeugen. Der Beanname wird in der BeanIds Klasse definiert.

Vorteil der Lösung: Copy&Paste wird in den Web Bundles reduziert.
Nachteil der Lösung: Man verwendet einen nicht-dokumentierten, implementierungsabhängigen Key.

Die Vorteile überwiegen jedoch. Credits für diese Lösung gehen an Eberhard Wolff (Springsource).

Für jeden LDAP-Server wird mit dem ldap-server Tag eine DefaultSpringSecurityContextSource Instanz registriert.

Jetzt fehlen für die beiden Server nur noch zwei AuthenticationProvider:

Das ldap-authentication-provider Tag erzeugt einen LdapAuthenticationProvider mit einem BindAuthenticator und einen DefaultLdapAuthoritiesPopulator.
(Ein BindAuthenticator prüft ob Passwort korrekt ist, ein LdapAuthoritiesPopulator erzeugt GrantedAuthorities aus der Gruppenzugehörigkeit des Users)

Mit der namespace-Konfiguration werden diese Objekte automatisch erzeugt. Soll für eine der beiden Objekte eine eigene Implementierung greifen, so kann das ldap-authentication-provider Tag nicht verwendet werden. Hier kommt wieder das custom-authentication-provider ins Spiel.

Beim Einsatz der namespace-Konfiguration registriert Spring Security im Hintergrund automatisch einen ProviderManager. Wenn nun (ebenfalls via namespace-Konfiguration) ein oder mehrere AuthenticationProvider konfiguriert werden, so werden sie automatisch dem ProviderManager bekannt gegeben. Dieser delegiert dann die eigentliche Authentifizierung an die konfigurierten AuthenticationProvider und erlaubt somit eine flexible Gestaltung der Authentifizierungslogik. Beispielsweise kann Spring Security den User erst gegen LDAP Server A authentifizieren, bei Misserfolg dann LDAP Server B anfragen.

Zurück zum Konfigurationsbeispiel aus Teil 1: Es ist noch unvollständig, da ein AuthenticationProvider fehlt. Spring Security liefert eine Reihe von Standardimplementierungen mit:

• DaoAuthenticationProvider
• LdapAuthenticationProvider
• OpenIDAuthenticationProvider
• CasAuthenticationProvider

Für das nächste Codebeispiel entscheiden wir uns für den DaoAuthenticationProvider, der Userattribute wie username oder password aus einem UserDetailService bezieht.

Mit dieser Konfiguration haben wir zwei statische User angelegt. Mit pmeier und hmueller kann man sich nun an der Webapplikation anmelden. Was passiert aber im Hintergrund ?
Das Tag authentication-provider registriert einen DaoAuthenticationProvider. Diesem Provider wird über das Tag user-service ein UserDetailsService vom konkreten Typ InMemoryDaoImpl übergeben und mit zwei Usern statisch konfiguriert.

Alternativ hätte man für das gleiche Resultat folgendes schreiben können:

Wichtig bei dieser Alternative ist das custom-authentication-provider Tag. Es sorgt dafür, das der ProviderManager unseren InMemoryProvider überhaupt kennt.

Im nächsten Teil sehen wir uns die Konfiguration für zwei LDAP Server an.

Gerade komme ich von der 2. Trivadis Java Lounge zurück. Im heutigen Vortrag mit dem Titel “Domain Driven Design” zeigten Adrian Hummel und Guido Schmutz wie mit Hilfe der Java Persistance API aus einem serviceorientierten “Transaction Script”-Ansatz ein eher OO-getriebenes “Rich Domain Model” entsteht, und wo genau die Vorteile liegen (weniger redundanter Code, erhöhte Testbarkeit und “mehr” Objektorientierung).

Ebenfalls spannend fand ich eine Variante des Builderpatterns, das mit unterschiedlichen Stati und Subklassen arbeitet. Dankeschön an den Gastgeber, es war ein interessanter Abend.

Mit der Version 2 von Spring Security (vormals Acegi Security) wurde die Konfiguration durch die Einführung neuer Tags erheblich vereinfacht. Die neuen Tags kapseln die Erzeugung der komplexen Filter- und Service-Beans und erhöhen somit die Lesbarkeit der Konfiguration.

Mit dem http-Tag legt der Entwickler die geschützten URLs fest und bestimmt die Authentifizierungsmethode wie z.B. Http Basic oder Forms Authentication.

Im folgenden XML-Schnipsel wird der Webauftritt in einen öffentlichen und einen geschützten Bereich aufgeteilt. Die öffentlichen Seiten beginnen mit dem URL-Prefix /public, alle anderen Seiten erfordern eine Authentifizerung.

Die Reihenfolge der intercept-url-Tags ist entscheidend. Hier gilt die Regel: “most specific first”. Im access-Attribut gibt der Entwickler ein oder mehrere sog. ConfigAttribute an. Ein ConfigAttribute definiert eine Rolle oder einen Authentifizierungzustand, der benötigt wird, um eine URL aus dem Pattern aufrufen zu können. Ach ja, die Patterns müssen der Ant Pattern Notation entsprechen. Die im Beispiel verwendeten Attribute (IS_AUTHENTICATED_FULLY und IS_AUTHENTICATED_ANONYMOUS) werden in der Klasse AuthenticatedVoter definiert.

Mit dem Tag http-basic hat der Entwickler automatisch eine Http Basic Authentication registriert, d.h. beim Zugriff auf den geschützten Bereich schickt Spring Security die Http Header für die Authentifizierung mit. Der Entwickler braucht sich darum gar nicht mehr kümmern.

Allerdings ist die Konfiguration noch nicht vollständig: Es fehlt noch ein AuthenticationProvider. Zwar haben wir durch das anonymous-Tag einen AnonymousAuthenticationProvider registriert, aber es fehlt natürlich ein Provider für den nicht-anonymen Zugriff, den wir uns im nächsten Teil ansehen werden.

Der MvnIndex ist äusserst praktisch, wenn man ein neues Projekt mit Maven aufsetzt.
Neben einer “Artifact”-Websuche gibts auch ein Eclipse Plugin für die Suche nach GroupId, ArtifactId und Version.

7 Jahre nach der ersten Auflage ist das Buch “Effective Java” von Joshua Bloch nun endlich in der zweiten Auflage erschienen. Der Klassiker wurde komplett runderneuert: Best-Practises für ‘neue’ Sprachelemente wie Generics und Enums kamen hinzu, veraltete Kapitel (wie der Ersatz von C-Strukturen) wurden gestrichen.

Neu ist auch das “Builder-Pattern”. Es kommt zum Einsatz, wenn ein Objekt viele optionale Variablen besitzt. Die bisherige, klassische Variante bei solchen Objekten ist das Schreiben von mehreren Konstruktoren (‘telescoping constructor’), die über unterschiedliche Anzahl von Parametern verfügen. Allerdings sinkt die Lesbarkeit bei mehr als 6 Parametern gewaltig (vor allem wenn die Parameter vom gleichen Typ sind).

Das “Builder-Pattern” verzichtet auf die ‘telescoping constructors’ und arbeitet stattdessen mit einer statischen inneren Klasse, die für das Erzeugen einer Instanz der äusseren Klasse zuständig ist. Der Konstruktor des Builder-Objekts enthält alle “Pflicht”-Variablen, die optionalen Variablen werden über (verkettbare) Methodenaufrufe hinzugefügt. Abschliessend wird die build Methode aufgerufen, die ein unveränderliches Objekt der äusseren Klasse erzeugt. Der Konstruktor der äusseren Klasse ist privat, d.h. nur ein Builder kann ein Objekt tatsächlich instanzieren:

Hier ein Beispiel: