Ü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.
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.).
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.