Nachdem es ja in meinem letzten Beitrag doch zahlreiche gute Beiträge in den Kommentaren gab und mich das Thema nicht losgelassen hat, will ich mal versuchen meine Erkenntnisse zusammenzufassen und eine neue Diskussion anzustoßen. Ich denke, dass ich meinen Prozess während ich mich mit Unit-Testing weiter auseinandersetze in einigen Beiträgen festhalten werden. Deshalb jetzt die ersten Gedanken zum Thema, bevor ich noch einen Test geschrieben habe.
Bisher war es für mich immer schwer das Konzept von Unit-Tests zu verstehen, weil ich das Gefühl habe, dass ich die Konzepte, die einem nahe gelegt werden nicht auf meinen bestehenden Code übertragen kann. Dazu ist zu sagen, dass man zuerst liest, dass es sowieso sehr schwer ist Tests nachträglich für bestehenden Code zu bauen, aber das sollte mich jetzt nicht davon abhalten es zu probieren, oder?
Unit-Tests sind dafür da Einheiten des Codes zu testen. Eben die Units oder Methoden oder Funktionen oder auch ganze Klassen, aber dann ebenfalls auf Methoden-Ebene. Ein Unit-Test soll sicherstellen, dass eine Methode mit gegebenen Parametern auch das entsprechende Verhalten zeigt. Und ist dann besonders nützlich, wenn man den Code oft verändert oder eben viele Leute an dem Code arbeiten.
Da kommt dann auch der Begriff des Test-Driven-Development zum tragen. Das Paradigma sieht vor, dass man sich überlegt, dass man eine bestimmte Klasse benötigt, die verschiedene Methoden besitzt, aber bevor man jetzt die Klasse implementiert, wird zunächst der Test dafür geschrieben. Der sicherstellen soll, dass die Methoden dann auch das gewünschte Verhalten zeigen. Soweit so gut.
Nur habe ich jetzt schon eine Applikation mit einer Menge Klassen und einer Menge Methoden. Und noch keine große Erfahrung mit Unit-Tests. Klar habe ich schon mal gehört, was man damit macht und auch schon mal einen Test geschrieben, aber eben an so Beispielen die auch beim Unit-Testing rangezogen werden. Eine Kontoklasse zum Beispiel.
Aber ich habe jetzt eine Webapplikation, die DB Anbindungen hat, Konfigurationsobjekte, die gemeinsame Aufgaben übernehmen etc. Deshalb werde ich mir eine relativ kleine Klasse suchen, die möglichst wenig Abhängigkeiten hat und trotzdem ein paar Funktionen im System erfüllt.
Damit ich aber nicht bei Null anfangen muss mit meinen Tests möchte ich noch eine kleine Funktion zeigen, die ich gerade programmiert habe:
function _logCall($p_args, $p_class, $p_method) {
$method = new ReflectionMethod($p_class, $p_method);
$log = "\r\n\r\n";
foreach($method->getParameters() as $i => $param) {
$log .= $param->getName() . ' => ' . $p_args[$i];
}
if(!is_dir('logs/' . $p_class)) {
mkdir('logs/' . $p_class);
}
file_put_contents('logs/' . $p_class . '/' . $p_method, $log, FILE_APPEND);
}
Aufgerufen dann mit:
_logCall(func_get_args(), __CLASS__, __FUNCTION__);
schreibe ich damit schöne Logfiles in denen der entsprechende Methodenaufruf mit Parametern, die auch im Live-Betrieb vorkommen erstellt wird. Daraus kann ich dann nutzen ziehen und entsprechende Testfälle bauen. Das ist zumindest die Idee.
Ähnliche Artikel:
