Jedem guten Software-Entwickler ist klar, dass Unit-Tests einen sehr wichtigen Beitrag zur Qualität von Software liefern und außerdem dem Entwickler ein gutes Gefühl geben. Oft ist es aber auf den ersten Blick nicht ganz einfach, den richtigen Weg zu finden, um Code automatisiert zu testen. Es gibt z.B. immer wieder Code, dessen Verhalten in irgendeiner Weise von der Systemzeit abhängt. Wenn man diesen Code nun testen will, müsste der Test eigentlich die Systemzeit manipulieren. In diesem Artikel möchte ich Wege zeigen, wie man solchen Code testen kann.

Die Nutzung von Log-Ausgaben für den Einblick in die internen Abläufe von Web-Servern gehört seit vielen Jahren zum normalen Handwerkszeug. Alle im Java-Umfeld verbreiteten Logging-Bibliotheken (das ungeliebte Java Logging API, das altgediente Log4J, der Quasi-Nachfolger Logback oder der Logging-Wrapper SLF4J) bieten Log-Levels an (z.B. TRACE, DEBUG, INFO, WARN und ERROR), um die Log-Ausgaben zu filtern. Während der Entwicklung ist es unproblematisch, wenn viele Logger auf der Stufe DEBUG stehen, da alle Log-Ausgaben von eigenen Requests erzeugt werden. Was macht man aber in der produktiven Umgebung?

Wir kommen nahezu alle irgendwann in die Situation, eine Präsentation erstellen zu müssen, HTML-Seiten für eine Web-Anwendung gestalten zu wollen oder wenigstens irgendwelche visuellen Darstellungen zu beurteilen. Nun haben die meisten von uns aber keine Ausbildung als Designer und daher fällt es oft schwer, ein Design objektiv zu bewerten oder Entscheidungen zu treffen, wo und wie man z.B. etwas auf einer HTML-Seite platziert.

Ich habe in den letzten Jahren kontinuierlich schlechte Erfahrungen mit Zielvereinbarungen und deren Verknüpfung mit variablen Gehaltsbestandteilen gemacht. Aus diesem Grund habe ich viel über dieses Thema gelesen und versucht, die Motivation zu verstehen, die hinter der Nutzung steht. Vor allem wollte ich verstehen, was sich Führungskräfte vom Einsatz erhoffen und wie die wirtschaftlichen, sozialen, kulturellen und psychologischen Hintergründe aussehen und welche Hindernisse dem Erreichen der Ziele am Ende im Weg stehen.

Ich möchte hier einige Beobachtungen zusammenfassen und strukturieren, um anschließend Maßnahmen abzuleiten, die DevOps und Agilität erst ermöglichen. Die Beobachtungen sind naturgemäß subjektiv und zeigen evtl. nur einen Teil der Zusammenhänge.