spring

Im Rahmen von Unit-Tests möchte man die Anbindung externer Systeme vermeiden um Stabilität der Tests zu gewährleisten. Leider hat man genau dann Probleme, wenn man gerade diese Anbindung oder die Integration mit externen Systemen testen möchte. Für solche Unit-Test mit integrativem Charakter kann man Mocks verwenden, die recht spezifisch für den jeweiligen Anwendungsfall selbst implementiert werden. Wenn es allerdings an die Implementierung eines Mail-Server Mocks geht, ist der Aufwand der Eigenimplementierung oft nicht mehr gerechtfertigt.

Die Berlin Expert Days 2012 haben ein sehr interessantes Programm. Neben bekannten Speakern erhalten auch weniger bekannte Speaker die Gelegenheit sich und Ihre Erfahrungen zu präsentieren. U.a. gibt es 4 Vorträge von Hypoport Mitarbeitern: Continuous Delivery in der Praxis – 7+ Lektionen von Jörg Müller Inversion of Flow von Arne Burmeister Modularisierung wagen: warum es sich lohnt, diesen Weg einzuschlagen (und wie man unterwegs überlebt) von Ansgar Konermann, Jacob Fahrenkrug MongoDB für Java Entwickler und Architekten – Schema Evolution und Maintenance: Was wurde uns am Anfang verschwiegen?

Ich bin froh, dass IntelliJ IDEA die Standard IDE bei uns ist. Hier ein kleines Beispiel wie flexibel – manche nennen es intelligent – IntelliJ ist:) Die Inspection unused variable warnt vor unbenutzten Variablen. Nach CleanCode lösche ich solche Variablen sehr gerne sehr schnell. Problematisch wird dies wenn man z.B. @Mock von Mockito oder @Resource von Spring verwendet. Was diese Annotationen inhaltlich machen gibt es ein anderes Mal. Für jetzt ist interessant, dass eine mit @Mock annotierte Variable nicht weiter im Code verwendet wird.

Bei Hypoport haben wir seit Jahren einen selbst entwickelten ESB im Einsatz. In unserem Team haben wir wenig KnowHow diesen zu nutzen und anzupassen. Die Anbindung und Erweiterung von externen Schnittstellen fällt daher nicht leicht. Erschwerend kommt hinzu, dass die Integration Flows nicht durch unser Continuous Delivery Skript automatisiert ausgerollt werden können. Wir standen vor der Entscheidung uns intensiv in diesen ESB einzuarbeiten oder es mit einer anderen Integrationslösung zu versuchen.

Wenn man einen ServletFilter für die eigene Webapp baut, dann muss man drei Methoden des Interfaces implementieren: init(), doFilter() und destroy(). Der Filter wird danach in die web.xml aufgenommen und startet zusammen mit der Webapp, wobei beim Starten des Filters seine init()-Methode aufgerufen wird. So weit die Theorie. Spring ermöglicht es, Filter im ApplicationContext zu definieren und ihnen damit Zugriff auf andere Beans zu bieten. Über die Namenskonvention Filtername == BeanId wird nun nicht mehr die Filterklasse in der web.