Samstag, August 26, 2006
Emails mit Spring
Bis Mittwoch hatte ich ziemlich intensiv am automatischen Versenden eines Newsletters für die Kontaktlinsen-Seite rumgebastelt. Ich hab's zu Anfang nicht hinbekommen das wirklich schön zu testen, weil ich die JavaMail-API nicht mocken konnte und die Spring-Mail-Abstraktion auch nicht weil die auch nicht ganz unabhängig von der JavaMail-API ist. Zumindest nicht wenn man MIME-Multipart-Mails verschicken muss. Naja, die Lösung war dann das Ausgliedern in einen eigenen MailService, der sehr einfach gehalten war, gegen den konnte ich dann gut testen.
Als Belohnung für den Aufwand mit dem Testen lief das Teil dann am Mittwoch komplett durch, hat ein paar tausend Mail in 30 Minuten fehlerfrei ausgeliefert. Das Feedback kam auch prompt, viel mehr Seitenzugriffe, auch noch an den folgenden Tagen, ein paar Bounces, ein paar Abmeldungen und ein paar Produktänderungen. Alles zusammen betrachtet war die Aktion sehr erfolgreich. Ab jetzt wird das Ganze einmal im Monat angeschoben, vollkommen automatisch dank der Spring-Quartz-Integration.
Mittlerweile hat sich das Investment Spring zu nutzen rentiert schätze ich.
Als Belohnung für den Aufwand mit dem Testen lief das Teil dann am Mittwoch komplett durch, hat ein paar tausend Mail in 30 Minuten fehlerfrei ausgeliefert. Das Feedback kam auch prompt, viel mehr Seitenzugriffe, auch noch an den folgenden Tagen, ein paar Bounces, ein paar Abmeldungen und ein paar Produktänderungen. Alles zusammen betrachtet war die Aktion sehr erfolgreich. Ab jetzt wird das Ganze einmal im Monat angeschoben, vollkommen automatisch dank der Spring-Quartz-Integration.
Mittlerweile hat sich das Investment Spring zu nutzen rentiert schätze ich.
Mittwoch, August 23, 2006
Wer niemals nie sagt, darf nie immer sagen.
Mal schön drüber nachdenken ob das so ist...
...und dann darüber nachdenken warum das zweite nie auch für jemanden der nie nie sagt okay gehen müsste.
...und dann darüber nachdenken warum das zweite nie auch für jemanden der nie nie sagt okay gehen müsste.
Sonntag, August 20, 2006
Tests mit Spring / EasyMock / JSF & Spring
Heute den Abschnitt über Tests im Spring-Buch von Eberhard Wolff gelesen, ist übrigens ein gutes Buch. Ich hab mit Eberhard mal bei PNP gearbeitet, er hat's drauf. Im Buch stand viel Wahres drin, ich musste erkennen, dass meine Tests durchaus noch Verbesserungspotential besitzen, hab dann heute auch prompt angefangen die Unit-Tests ohne Spring und wo nötig auf EasyMock umzustellen. EasyMock ist etwas gewöhnungsbedürftig, aber dann echt Klasse. Macht die Unit-Tests mal echt unabhängig.
Daraufhin weitergelesen und erkannt, dass ich die Verbindung von Spring und JSF schlecht umgesetzt habe. Dieser suboptimale Ansatz bestand in der Verwendung eines ServiceLocator-Patterns, wobei lediglich ein selbstkreierter ServiceLocator in die JSF-Beans gedrückt wurde. Den Ansatz hab ich aus einem Artikel auf JavaWorld.com. Keine Ahnung wann die JSF-Integration in Spring Einzug gehalten hat, aber ich nehme mal an dass die zur Zeit des Artikels noch nicht verfügbar war. Jetzt sollte man auch jeden Fall den den DelegatingVariableResolver verwenden um die Spring-Beans in der faces-config.xml in die JSF-Beans zu drücken. Damit erstreckt sich die Dependency Injection dann auch bis in die JSF-Beans und alles wird gut.
Resultat aus dem Umbau: Kein ServiceLocator mehr, das ist normalerweise noch eine zusätzliche Stelle gewesen in denen ich zumindest die Service-Beans registrieren musste (zusätzlich zur Spring-Konfiguration). Jetzt gibt's das Teil einfach nicht mehr. Mehr Übersichtlichkeit, es ist jetzt in der JSF-Konfig klar zu erkennen auf welche Services zugegriffen wird. Sehr praktisch wenn mal was ändern will um abzuschätzen wo der Spass sich auswirken könnte. Das gute Gefühl, dass alles seine Richtigkeit hat.
Und abschließend mal wieder die Erkenntnis, dass Unit-Tests die Qualität des Codes hinsichtlich der Struktur automatisch verbessern, weil einfach keinen Spass macht schlecht strukturierten Code zu testen.
Daraufhin weitergelesen und erkannt, dass ich die Verbindung von Spring und JSF schlecht umgesetzt habe. Dieser suboptimale Ansatz bestand in der Verwendung eines ServiceLocator-Patterns, wobei lediglich ein selbstkreierter ServiceLocator in die JSF-Beans gedrückt wurde. Den Ansatz hab ich aus einem Artikel auf JavaWorld.com. Keine Ahnung wann die JSF-Integration in Spring Einzug gehalten hat, aber ich nehme mal an dass die zur Zeit des Artikels noch nicht verfügbar war. Jetzt sollte man auch jeden Fall den den DelegatingVariableResolver verwenden um die Spring-Beans in der faces-config.xml in die JSF-Beans zu drücken. Damit erstreckt sich die Dependency Injection dann auch bis in die JSF-Beans und alles wird gut.
Resultat aus dem Umbau: Kein ServiceLocator mehr, das ist normalerweise noch eine zusätzliche Stelle gewesen in denen ich zumindest die Service-Beans registrieren musste (zusätzlich zur Spring-Konfiguration). Jetzt gibt's das Teil einfach nicht mehr. Mehr Übersichtlichkeit, es ist jetzt in der JSF-Konfig klar zu erkennen auf welche Services zugegriffen wird. Sehr praktisch wenn mal was ändern will um abzuschätzen wo der Spass sich auswirken könnte. Das gute Gefühl, dass alles seine Richtigkeit hat.
Und abschließend mal wieder die Erkenntnis, dass Unit-Tests die Qualität des Codes hinsichtlich der Struktur automatisch verbessern, weil einfach keinen Spass macht schlecht strukturierten Code zu testen.
