Das Testen von Web-Seiten mit Selenium ist dank umfangreicher Tools sehr effizient möglich. Mit dem Firefox-PlugIn Selenium-IDE lassen sich die Testschritte aufzeichnen und später dann wieder abspielen. Um eine echte Testautomatisierung zu erreichen wird häufig auch eine Integration mit einem agilen Test-Tool – wie z.B. dem Robot Framework – vorgenommen, welches seine eigene Selenium-Implementierung mitbringt.

Das automatisierte Testen von Webseiten wird jedoch in dem Moment jäh aus gebremst in dem eine Seite angesteuert, die mit SSL verschlüsselt ist, jedoch ein nicht autorisiertes Zertifikat nutzt. Der Browser macht eine Vollbremsung und es öffnet sich ein Dialog, der den Benutzer auffordert das Zertifikat zu akzeptieren. Das ist natürlich nicht wirklich praktisch während eines automatisierten Tests.
(weiterlesen…)

Automatisierte Builds und Tests setzen wir bei codecentric schon seit langem ein, jedoch fanden die Buildmonitore bis heute noch keinen Einzug ins Gebäude. Zwar ist der Status bisher auch einfach einsehbar gewesen, doch ihn zum Beispiel beim Kaffee zu sehen ist wichtig. Denn gerade wenn man mal nicht daran denkt nachzuschauen ist der eigene Build oft rot.

Letzte Woche mussten ich einen Webservice-Client erweitern, sodass er die Verarbeitung abbricht, wenn die Gegenseite nicht schnell genug ein Ergebnis liefert. Das Ganze ist mit spring-webservices implementiert und verwendet die WebServiceTemplate Klasse. (weiterlesen…)

2009 ist nun schon ein paar Tage vorbei, so daß vielleicht ein kleiner Jahresrückblick angemessen wäre. Kürzlich sagte ich noch zu jemandem: “Och ich bin erst gerade mal anderthalb Jahre bei codecentric”, aber dies ist doch schon ein beachtlicher Zeitraum. 2009 war ein sehr ereignisreiches Jahr; es gibt sehr viel auf das es sich lohnt zurückzublicken. Zum Beispiel auf 85 Blogeinträge. Aber es gibt auch vieles in der Zukunft auf das es sich hinzuarbeiten lohnt. Ich bin sehr stolz auf unser Team und das was wir erreicht haben. (weiterlesen…)

Eine der großen Stärken der Java Plattform ist die automatische Speicherverwaltung. Jeder der schon mal mit C/C++ programmiert hat und sich um die Allokation und Freigabe von Speicher selber kümmern musste, weiß diese Eigenschaft der Java Runtime zu schätzen. Die in der Praxis häufig aufgetretenen Probleme, dass Speicher zu früh  (corrupted pointer) oder unvollständig (memory leak) freigegeben wurden sind damit grundsätzlich behoben. Die Frage ist: Warum schreibe ich dann überhaupt diese Blog Einträge?

Leider kann auch eine implizite Speicherverwaltung, wie Java sie hat, nicht verhindern, dass man Anwendungen programmiert, die zu Speicher Problemen führen, obwohl eine manuelle Allokation in Java nicht möglich und per Spezifikation ausgeschlossen ist. Das Resultat solcher Fehler ist dann in der Regel eine Ausnahme vom Typ: java.lang.OutOfMemoryError.

(weiterlesen…)

Jeder Java Programmierer wird früher oder später über folgende Ausnahme stolpern: java.lang.OutOfMemoryError.

Mit ein wenig Glück passiert das noch während der Entwicklung. Tritt diese Ausnahme aber im produktiven Betrieb auf, erhält man schnell eine ungewollte Aufmerksamkeit im Management, da ein Java OutOfMemoryError in der Regel gleichbedeutend mit einem Produktionsausfall ist. Die Ursachen für diesen Fehler in der JVM sind vielfältig und nicht immer einfach zu analysieren. In der Praxis sehe ich täglich, dass Server jede Nacht neu gestartet werden um kontinuierlich anwachsendem Speicher Herr zu werden oder aber Anwendungen regelmäßig aus vermeindlich unerklärlichen Gründen ausfallen, auch wenn ein java.lang.OutOfMemoryError im Log darauf hin weist, dass der Hunger der Anwendung nach mehr Speicher einfach zu groß war.

(weiterlesen…)