Hallo!

Ich hab mal das verregnte Wochenende genutzt, und habe ein kleines Einführungstutorial zum Theman Unittesting mit DUnit geschrieben. Ich habe es bewusst kurz gehalten, damit es einen schnellen Einstieg in das Thema ermöglicht. Auch wenn ich mich sehr zusammenreißen musste, es kurz zu halten. Über das Theman könnte man ganz problemlos Bücher schreiben (das ist dann das Projekt für den Winter )

Vielen Dank auch an dieser Stelle an zuma fürs Korrekturlesen.

Viel Spaß damit!

Edit: Crosspost: www.delphipraxis.net...sting-mit-dunit.html
Edit: Seitenzahlen hinzugefügt

Ich kenne mich mit dem Thema schon aus hab aber kurz mal drüber gelesen. Hast es meiner Meinung nach gut beschrieben und die Beispiele sollte auch jeder verstehen. Auf jeden Fall hilfreich für Personen die sich mit dem Thema noch nicht auskennen.

Aber auch für Personen wie mich da ich bisher noch kein DUnit kannte. Habe damit auf PHP und Java basis gearbeitet.

Kann es auf jeden Fall nur weiter empfehlen eine Anwendung ist schließlich nur so gut wie die Tests dazu.

Sehr nett geschrieben.

Zitat:

Ich weiß: in Deiner Software gibt es natürlich keine Programmfehler. Aber nehmen wir mal den unwahrscheinlichen Fall an, dass der Praktikant heimlich eine Quellcodedatei geändert hat, ohne dass wir davon wussten. Und dabei produziert er natürlich einen Fehler: function TCalculator.Add(A, B: integer): Integer; begin //modified by Praktikant result := A + A + B; end; Dieser Fehler wäre bisher erst beim Kunden aufgefallen. Denn wer kommt schon drauf, dass der Praktikant gerade hier einen Fehler einbaut....

Ich wollte ja keinem Kollegen unterstellen, dass er fehlerhafte Software schreibt. Also hab ich den schwarzen Peter einfach zum Praktikanten geschoben.

Schön geschrieben. Aber Praktikant möchte ich bei dir auch nie sein
Der letzte Satz fasst das nochmal gut zusammen

Gefällt mir sehr gut Endlich auch mal wieder ein PDF, in dem es eine verschachtelte, übersichtliche Inhaltsangabe gibt. Die Einleitung kann ich hier an meiner Uni gut nachvollziehen. Da denkt auch jeder, dass man beim Schreiben von Programmen keine Tests braucht, weil der Code übersichtlich ist. Allerdings sind nicht alle Programme Taschenrechner auf Konsolenbasis. Letztendlich wird man zumindest als Nicht-Informatiker in solche Testszenarien gar nicht (mehr) eingeführt.
Zur DUnit noch ein zwei Fragen, die nicht im Tutorial angesprochen wurden: Beschränkt sich das Testen nur auf Funktionen einer Klasse, oder kann ich auch mehrere Klassen gleichzeitig testen? Wie gut reagieren die Testprozeduren auf Refactoring?

Regan hat folgendes geschrieben :

Da denkt auch jeder [...] Nicht-Informatiker

Hu, kurz hattest du mich halbwegs geschockt .

Regan hat folgendes geschrieben :

Beschränkt sich das Testen nur auf Funktionen einer Klasse, oder kann ich auch mehrere Klassen gleichzeitig testen?

Dann wäre es streng genommen kein Unit-Test mehr. Natürlich haben viele Klassen weitere Abhängigkeiten, die sollten aber trotzdem nicht gleichzeitig mitgetestet werden => Thema Mocking. Letztendlich ist ja aber die Testmethode in keiner Weise an eine bestimmte Testklasse gekoppelt, also kannst du darin veranstalten, was du willst.

Regan hat folgendes geschrieben :

Wie gut reagieren die Testprozeduren auf Refactoring?

Nicht besser oder schlechter als gewöhnliche Methoden, würde ich mal behaupten . Auf jeden Fall fallen sie nicht zur Last, schließlich spielt Unit Testing bei Refactoring erst so richtig seine Stärke aus. Bei einem Non-Breaking Change, der also die Schnittstelle der Klasse nicht verändert, bewahrt es dich vor Regression Bugs; bei einem Breaking Change, bei dem auch der Test angepasst werden muss, zeigen dir die dort nötigen Änderungen gleich, ob die neue Schnittstelle von außen auch wirklich Sinn macht - quasi Behavior Driven Design (BDD), was genauso wie Regressionen in der Einleitung angesprochen/angedeutet wurde, wollte den zweien nur mal noch Fachwörter zuordnen .

Als Ergänzung zur Antwort von Kha.
DUnit kann natürlich mehrere Klassen testen. Allerdings ist es eher darauf ausgelegt, sie einzeln zu testen. Wenn eine Klasse Abhängigkeiten von anderen Klassen hat, muss man ihr ein definiertes Testumfeld schaffen. Das heißt, im Setup erstelle ich diese Testumfeld (das auch aus Instanzen anderer Klassen bestehen kann) und teste dann aber nur diese eine Klasse, ob sie das macht, was ich erwarte.
Dabei ist es sinnvoll, schon in der Entwicklung der Software darauf zu achten, dass man testbaren Code schreibt. Das heißt meistens: kleine Klasse, die nur eine bestimmte Aufgabe haben. So lässt sich viel einfacher sicherstellen, dass diese Klasse diese eine Aufgabe auch richtig ausführt.
Des weiteren natürlich die Trennung der Präsentationsebene vom Logiklayer.

Zum Thema Refactoring: Robert C. Martin weißt in seinem Buch "Clean Code" auf jeder 2. Seite darauf hin, dass man testbaren Code schreiben möge. Und dafür auch Testfälle erstellen soll. Warum: weil es einem die Angst nimmt, Refactorings vorzunehmen, und so aus schlechten ("verottetem") Code guten, sauberen Code zu machen. Unittests erlauben uns den Luxus, bereits "fertigen", funktionierenden Code umzuschreiben. Denn wenn er hinterher nicht mehr den Spezifikationen entspäche, würden wir es sehr früh merken.

Jens

Vielen Dank für die Klarstellungen. Das Thema Refactoring ist mir bei diesen Tests als leidiges Thema in Java in Erinnerung geblieben. Damals konnte ich die JUnit bei einer Umstruktrierung des Programms nicht dazu bewegen, ihre Methoden anzupassen.

Nersgatt hat folgendes geschrieben :

Denn wenn er hinterher nicht mehr den Spezifikationen entspäche, würden wir es sehr früh merken.

Setzt natürlich auch voraus, erst einmal gute Testszenarien zu haben. Aber dazu hat Kha mit BDD und TDD schon genug gesagt.