Autor Beitrag
Nersgatt
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1565
Erhaltene Danke: 270


Delphi 10 Seattle Prof.
BeitragVerfasst: Mo 20.06.11 09: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 :D )

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 10:34, insgesamt 2-mal bearbeitet

Für diesen Beitrag haben gedankt: Regan, zuma
thepaine91
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 763
Erhaltene Danke: 27

Win XP, Windows 7, (Linux)
D6, D2010, C#, PHP, Java(Android), HTML/Js
BeitragVerfasst: Mo 20.06.11 09: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. :P
j.klugmann
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Mo 20.06.11 09:47 
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....

:mrgreen: :mrgreen:
Nersgatt Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1565
Erhaltene Danke: 270


Delphi 10 Seattle Prof.
BeitragVerfasst: Mo 20.06.11 09:55 
Ich wollte ja keinem Kollegen unterstellen, dass er fehlerhafte Software schreibt. Also hab ich den schwarzen Peter einfach zum Praktikanten geschoben. :wink:

_________________
Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
Flamefire
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 1207
Erhaltene Danke: 30

Win 10
Delphi 2009 Pro, C++ (Visual Studio)
BeitragVerfasst: Mo 20.06.11 16:32 
Schön geschrieben. Aber Praktikant möchte ich bei dir auch nie sein :D
Der letzte Satz fasst das nochmal gut zusammen ;)
Regan
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Beiträge: 2157
Erhaltene Danke: 72


Java (Eclipse), Python (Sublimetext 3)
BeitragVerfasst: Mo 20.06.11 22:14 
Gefällt mir sehr gut :zustimm: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Mo 20.06.11 23:02 
user profile iconRegan hat folgendes geschrieben Zum zitierten Posting springen:
Da denkt auch jeder [...] Nicht-Informatiker
Hu, kurz hattest du mich halbwegs geschockt :mrgreen: .

user profile iconRegan hat folgendes geschrieben Zum zitierten Posting springen:
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.

user profile iconRegan hat folgendes geschrieben Zum zitierten Posting springen:
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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1565
Erhaltene Danke: 270


Delphi 10 Seattle Prof.
BeitragVerfasst: Di 21.06.11 07: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
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Beiträge: 2157
Erhaltene Danke: 72


Java (Eclipse), Python (Sublimetext 3)
BeitragVerfasst: Di 21.06.11 10: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.
user profile iconNersgatt hat folgendes geschrieben Zum zitierten Posting springen:
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 user profile iconKha mit BDD und TDD schon genug gesagt.