javablog.ch

Zur Qualitätssicherung eines Softwareprojekts gehören neben Unittests auch statische Codeanalysen. Tools wie Checkstyle, Findbugs oder PMD untersuchen Java-Klassen und bewerten den Code anhand verschiedener Metriken.

Zwar können diese Checks einen manuellen Codereview nicht ersetzen, aber Standardfehler und bekannte Anti-Patterns werden zuverlässig erkannt. Für jedes der genannten Tools gibt es ein Eclipse-Plugin, das die betreffenden Codestellen markiert. Die Anzeige der Fehler ist aber nicht ausreichend: Bei schwerwiegenden Verstössen soll auch der Build scheitern, ansonsten besteht die Gefahr, dass der Code nicht korrigiert wird. Aber wie kann man das umsetzen ?

Mit Maven 2 geht dies einfach mit einer Plugin-Konfiguration innerhalb des “build”-Elements.

Hier ein Projektbeispiel für die PMD Analyse:

Mit dieser einfachen Konfiguration wird sichergestellt, dass der Code keine PMD-Verstösse der Kategorie 1 und 2 enthält. Zudem ist garantiert, dass der Build bei Copy&Paste von 100 Wörtern (bzw. Tokens) scheitert. Praktisch !

Wenn Bibliotheken von Drittherstellern nicht vollständig dokumentiert sind, und dann auch noch der Quelltext fehlt, kann ein Decompiler Abhilfe schaffen. Leider wurde die Entwicklung des kostenlosen Decompilers “JAD” von Pavel Kouznetsov eingestellt.

Seit letztem Jahres steht eine Alternative namens “JD” ebenfalls kostenlos zur Verfügung. Das Projekt ist zu finden unter http://java.decompiler.free.fr/ und bietet neben einer schicken Standalone GUI-Version auch ein Eclipse-Plugin an. Obwohl es noch nicht ganz fertig ist, hinterlässt das Tool einen sehr guten Eindruck.

Apache Maven ist ein fantastisches Buildsystem, allerdings sind manche Plugins eher spartanisch dokumentiert. Für mehr Klarheit sorgt das maven-help-plugin mit seinem “describe“-goal, welches alle Goals eines Plugins inkl. der möglichen Parameter beschreibt. Beispielaufruf:

mvn help:describe -Dplugin=org.codehaus.mojo:findbugs-maven-plugin -Dfull

Ebenso hilfreich ist das “effective-pom“-goal, mit dem ein POM inkl. aller geerbten Eigenschaften ausgegeben wird. Vor allem bei grossen Projekten mit vielen Parents ist die generierte Übersicht hilfreich. Beispiel:

mvn help:effective-pom

In der letzten Zeit gabs weniger Posts im Blog. Dies hatte auch einen Grund: jPrep. Seit ein paar Monaten beschäftige ich mit der Entwicklung von iPhone / iPod touch Applikationen. Die erste habe ich nun auf den Appstore gestellt.

jPrep ist ein Vorbereitungstool für die SCJP 6 (Sun Certified Java Programmer) Zertifizierung. In Form eines Quiz mit 175 Fragen wird der Anwender auf die Prüfung vorbereitet. Eine übersichtliche Statistik zeigt Stärken und Schwächen in den einzelnen Themengebieten auf. Als zusätzlichen Feature können die Quizfragen zu einer eigenen Merkliste (“MyList”) hinzugefügt werden. Für die meisten Fragen habe ich einen direkten Link auf die Java Reference (API oder die Java Language Specification) eingepflegt, der über den (applikationsinternen) Browser geöffnet werden kann. Hier ein paar Screenshots:

Themenübersicht

Beispielfrage

Statistik

MyList

Umgesetzt wurde es komplett mit Objective-C. Als Java-Entwickler muss man sich zwar an manche Besonderheiten der Sprache und der IDE erst mal gewöhnen, aber wenn diese Hürde geschafft ist, macht iPhone-Entwicklung richtig Spass. Apropos Spass: Für die Pflege der Fragen habe ich eine eigene Webapplikation mit Ruby On Rails geschrieben. Ging definitiv schneller als mit Java

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.