Unit Testing sinnvoll?

[s.h.a.r.k]

Wie viel Zeit wird von euch denn für solche Unit-Tests denn investiert? Ich persönlich habe den Sinn zwar schon verstanden, sehe es aber teilweise als unwirtschaftlich an, wenn ich mir da so manche Videos angeschaut habe. Klar, wenn ein blöder Fehler versteckt ist, kann es sein, dass ich (also der Programmierer) dann teurer kommt, da er erst mal den Fehler ausfindig machen muss. Aber eine Kennzahl wäre hier schon mal interessant zu wissen. Gerne auch prozentual zu den Stunden, die wirklich am Projekt selbst gearbeitet wird.

[Assarbad]

Zitat von s.h.a.r.k:

Wie viel Zeit wird von euch denn für solche Unit-Tests denn investiert? Ich persönlich habe den Sinn zwar schon verstanden, sehe es aber teilweise als unwirtschaftlich an, wenn ich mir da so manche Videos angeschaut habe.

Soviel wie es eben benötigt.

Unit-Tests können teilweise ja sogar als Ersatz einer Spezifikation dienen. Die Idee ist ja bei einer möglichst großen Abdeckung mit Tests die darunterliegende Implementation beliebig abändern zu können und sicher zu sein, daß es noch funktioniert.

Abgesehen davon ist natürlich "unwirtschaftlich" etwas weithergeholt. Wenn man bedenkt daß die meisten Projekte mit schlechter Testabdeckung und/oder Planung schwer wartbar sind und die Wartung (und Fehlersuche/-behebung) sehr lange dauert, relativiert sich das wieder.

Sobald du mal, statt eine Funktion 100x über irgendwas laufen zu lassen und trotzdem nicht zu wissen ob deine Änderung korrekt war, eine kleine Änderung gemacht hast und dann deine Tests drüberlaufen lassen kannst und mit Gewissheit weißt, daß die Änderungen bei erfolgreichem Testdurchlauf korrekt sind, dürfte dir die Wirtschaftlichkeit klar werden

[s.h.a.r.k]

Muss mir dann wahrlich mal anschauen, wie ich denn diese Tests dann erstelle. Mir erscheint es nur bei kleineren Projekten weniger sinnvoll, vor allem weil ich immer alleine dran gearbeitet hatte. Aber wenn mehrere Personen an etwas frickeln, wird es dann wahrlich schon interessanter. Danke für die nochmalige Erläuterung

[Assarbad]

Zitat von s.h.a.r.k:

Mir erscheint es nur bei kleineren Projekten weniger sinnvoll, vor allem weil ich immer alleine dran gearbeitet hatte.

Aaaah, verstehe. Darauf willste hinaus. Das ist natürlich korrekt. Bei kleinen Tools nimmt man gern Abkürzungen. Ich habe mich allerdings schon mehrfach dabei erwischt, daß Abkürzungen dazu führten, daß ich mich nach einem halben Jahr oder länger fragte, was mein Ich in der Vergangenheit sich wohl bei dieser oder jener Sache dachte. Da ist es dann gut Kommentare oder Tests für die entsprechende Funktion/Zeile zu haben. Die Tests sind in dem Sinne ja auch durchaus Dokumentation.

Aber die Integration der Tests kann in der Tat problematisch sein ... je nachdem was man schreibt und in welchem Stil. In diversen Sprachen haben sich da Standards herausgebildet. Was es bei Delphi ist, weiß ich nicht ... würde mich allerdings durchaus interessieren

[stahli]

Ich bin da etwas hin- und hergerissen.

Über solche Tests kann man doch auch nur einige Dinge und Situationen prüfen, die man in einem starren Ablauf nachvollziehen kann.
Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Ein weiteres Problem ist in der GUI-Anbindung zu sehen. Gibt es hier irgendwelche (zeitkritischen) Probleme, kann man das mit Unittesting auch nicht feststellen.
Da scheint mir ein GUI-Testing schon sinnvoller, aber so richtig überzeugt mich das auch nicht (vom Aufwand/Nutzen her).

Also ich bin noch nicht sicher, was ich davon halten soll (ob sich der Aufwand lohnt).

[Assarbad]

Zitat von stahli:

Über solche Tests kann man doch auch nur einige Dinge und Situationen prüfen, die man in einem starren Ablauf nachvollziehen kann.
Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Aaah. In der Tat. Hierbei kommen dann "Integration Tests" und "System Tests" zum Einsatz.

Stell dir den jeweiligen Unit Test einfach als Möglichkeit vor die dokumentierte oder implizierte Funktionsweise der Funktion zu testen, jedoch nicht deren Einbindung in das Produkt. Dafür gibt es, wie gesagt, wiederum andere Varianten.

Zitat von stahli:

Ein weiteres Problem ist in der GUI-Anbindung zu sehen. Gibt es hier irgendwelche (zeitkritischen) Probleme, kann man das mit Unittesting auch nicht feststellen.

Absolut korrekt. Aber hier kann bspw. die Trennung deiner Anwendung in verschiedene Ebenen (siehe http://de.wikipedia.org/wiki/3-Tier#...en-Architektur) helfen. Vorteil: du kannst deine Tests bspw. in einer Kommandozeilenversion automatisieren. Damit haste sicher in den meisten Fällen mehr als 90% der Funktionalität einer Anwendung abgedeckt, es sei denn du mischst Logik und Präsentation (was Delphi leider ein wenig fördert, s.o.).

Zitat von stahli:

Also ich bin noch nicht sicher, was ich davon halten soll (ob sich der Aufwand lohnt).

Okay, mach es doch einfach mal anhand eines kleinen Projekts. Und dann notierst du exakt den Zeitaufwand. Ich denke aufgrund der Erfahrung mit Projekten ohne Tests kannste es sehr bald abschätzen. Aber Gold wert sind Unit Tests sobald du eine tiefgreifende Änderung am System vornehmen willst.

[BUG]

Zitat von stahli:

Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Man kann natürlich nicht alles abdecken.
Aber überlege, was du testest, wenn du "live" beim Programmieren testest.

z.B.

A,B: Integer

Dann hast du zum Beispiel Eigenschaften wie:
1) A < 0, A > 0, A = 0
2) B < 0, B > 0, B = 0
3) A < B, A > B, A = B

Wenn du für alle diese Kombinationen von Eigenschaften ein Beispiel testest, solltest du beim Addieren relativ gut hinkommen.
(Ob das wohl in der Praxis irgendjemand so ausführlich macht )

Zusätzlich kannst du dir Eingabewerte merken, bei denen es in der Vergangenheit Probleme gab:
Wenn mal bei ADD(6,-4) = 42 herauskam und du den Fehler gefixt hast, dann kannst du sichergehen, das der Fehler nicht nochmal auftritt (z.B. wenn du wegen eines anderen Problems eine frühere Version aus dem SVN holst).

Und dann gibt es noch die Möglichkeit, Fehler zu testen, die einfach häufig sind:
Grenzfälle, Off-By-One-Errors, usw.


Zudem kannst du beim Unit-Test ja relativ gut abschätzen, wo der Fehler herkommt, was beim GUI-Testen schwerer ist.

[mquadrat]

Wir stellen gerade auf Test-Driven-Developement um. Also ja, ich denke schon, dass Unit-Tests Sinn machen

Kleinere Projekte eignen sich hervorragend zum üben, bevor man sich an die alten großen Bestandsprojekte macht.

[Viktorii]

Bezüglich #24: Also gibt es sowas in Delphi nicht (viel)?

Stimmt die These von mquadrat also doch irgendwo??

http://www.delphipraxis.net/157452-d...re-design.html

[Assarbad]

Zitat von Viktorii:

Stimmt die These von mquadrat also doch irgendwo??

http://www.delphipraxis.net/157452-d...re-design.html

Ich würde ihm zustimmen. Es läuft im Grunde auf das gleiche Argument hinaus wie meines, daß Delphi zu schludriger Programmierung verleitet ... (und die oft kopierten Codebeispiele ebenso).