Autor |
Beitrag |
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Mo 20.06.11 08:06
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
Einloggen, um Attachments anzusehen!
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
Zuletzt bearbeitet von Nersgatt am Di 21.06.11 09:34, insgesamt 2-mal bearbeitet
Für diesen Beitrag haben gedankt: Regan, zuma
|
|
thepaine91
Beiträge: 763
Erhaltene Danke: 27
Win XP, Windows 7, (Linux)
D6, D2010, C#, PHP, Java(Android), HTML/Js
|
Verfasst: Mo 20.06.11 08:27
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.
|
|
j.klugmann
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 20.06.11 08:47
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Mo 20.06.11 08:55
Ich wollte ja keinem Kollegen unterstellen, dass er fehlerhafte Software schreibt. Also hab ich den schwarzen Peter einfach zum Praktikanten geschoben.
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
Flamefire
Beiträge: 1207
Erhaltene Danke: 31
Win 10
Delphi 2009 Pro, C++ (Visual Studio)
|
Verfasst: Mo 20.06.11 15:32
Schön geschrieben. Aber Praktikant möchte ich bei dir auch nie sein
Der letzte Satz fasst das nochmal gut zusammen
|
|
Regan
Beiträge: 2157
Erhaltene Danke: 72
Java (Eclipse), Python (Sublimetext 3)
|
Verfasst: Mo 20.06.11 21:14
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?
|
|
Kha
Beiträge: 3803
Erhaltene Danke: 176
Arch Linux
Python, C, C++ (vim)
|
Verfasst: Mo 20.06.11 22:02
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 .
_________________ >λ=
Für diesen Beitrag haben gedankt: Regan
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 21.06.11 06:20
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
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
Für diesen Beitrag haben gedankt: Regan
|
|
Regan
Beiträge: 2157
Erhaltene Danke: 72
Java (Eclipse), Python (Sublimetext 3)
|
Verfasst: Di 21.06.11 09:00
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.
|
|
|