28 May – 1 June shared nifty ideas for development, ticketing, Windows monitoring and hotkeys, as well as a couple events to look forward to.
Ronny started by looking at the latest from AutoHotkey and Christian recommended his best ticket system for business.
Gunnar then explained test-driven development and how it reduces the need to debug, while Birger discovered a discarded traffic light that could have been handy as an Icinga/Nagios alerter .
Phillip followed with Part 6 of his NSClient ++ blog series, offering a guide to monitoring various file attributes such as size, age and version.
Lastly, Eva counted down 149 days to OSMC 2012 with a video of a presentation by Christopf Siess – “A Performance Comparison of Nagios Monitoring Solutions”.
She also reflected on RootCamp Berlin 2012 and looked ahead to the Puppet Camp coming to Nuremberg in October, in time for the OSMC. We welcome you to combine the two and join us!
NETWAYS Blog
Test-driven Development
Beim Test-driven Development handelt es sich um einen Programmieransatz des Extreme Programming, der auf Unit Tests basiert und höhere Produktivität verspricht.
Bevor der Code einer Anwendung geändert werden kann, z.B., um ein neues Feature zu implementieren, muss beim Test-driven Development zunächst ein Unit Test geschrieben werden.
Dieser Test beschreibt so minimal wie möglich die fehlende Funktionalität und gibt so z.B. die öffentliche Schnittstelle für neue Klassen und Funktionen vor. Wichtig ist, dass der neue Test fehlschlägt, z.B. weil es die verwendete Funktion noch nicht gibt oder sie die getestete Funktionalität nicht vollständig implementieren.
Erst dann sollte der eigentliche Code der Anwendung solange angepasst werden, bis der neue Test sowie alle evtl. schon vorhandenen Tests erfolgreich ausgeführt werden können.
Danach können weitere Tests geschrieben werden, die z.B. weitere Eingabewerte für die Funktion berücksichtigen. Dieser Kreislauf wird dann solange wiederholt, bis man sicher ist, dass die neue Funktion einwandfrei funktioniert.
Sobald die neue Funktion fertig-implementiert ist, kann man den Code noch – sofern notwendig – aufräumen. Dank der Unit Tests wird beim Refactoring und auch bei späteren Änderungen am Code vermieden, dass sich wieder Bugs einschleichen, wodurch weniger Zeit benötigt wird, den Code zu debuggen.
