Unit Testing sinnvoll?

[stahli]

Hallo alle,

ich habe mir mal Videos zum Unit Testing angesehen und der Sinn erschließt sich mir noch nicht wirklich.

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

GUI-Testing wie TestComplete ist natürlich schon beeindruckend, allerdings im Handling selbst sehr komplex und nicht gerade billig ;-)

Wirklich hilfreich scheint mir aber nur letzteres...
Was meint Ihr?

[Assarbad]

Erstmal: ja. Unit Testing stellt sicher, daß kleine Code-Einheiten (eben die "Units", aber nicht im Delphi-Sinn) entsprechend ihrer Spezifikation funktionieren. Um es ein Stück weiter zu treiben: Unit Tests können als Spezifikation herhalten.

Zitat:

Zitat von stahli (Beitrag 1057987)

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

Du vergißt, daß für das komplette Programm auch Integrationstests (funktionieren die verschiedenen "Einheiten" und "Module" zusammen?) und Systemtests (wie funktioniert das ganze dann quasi aus Benutzersicht?) fehlen.

[Meflin]

Ist anschnallen sinnvoll?

Mehr muss man dazu imo nicht sagen :P

[mleyen]

Anschnallen ist ein ungünstig gewähltes Vergleichswort.
Eher sowas wie:
"Ein gebautes System welches erkennt was du beim Losfahren, deiner Meinung nach zu urteilen, alles falsch gemacht haben könntest"

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1057987)

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

Das ist ja auch dann kein Unit-Test mehr sondern Modul-/Integrations-/Systemtests.

[mjustin]

Ja, so wie Zähneputzen ("Only Floss the Teeth You Want to Keep"). GUI Tests sind ebenfalls (trotz des Aufwands) für größere Projekte oft erfolgsentscheidend. Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

In DUnit sind übrigens auch Funktionen zum GUI Test enthalten, ich habe damit noch nicht selber gearbeitet aber als 'minimalistische' Alternative zu TestComplete sind sie sicher brauchbar.

[hoika]

Hallo,

Zitat:

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...

Nein und ja ...

Bsp.

Delphi-Quellcode:

function Add2(Value: Integer);
begin
  Result:= Value+2;
end;

Jetzt kommt einer und ändert was

Delphi-Quellcode:

function Add(Value: Integer; AddValue: Integer);
begin 
  Result:= Value+AddValue;
end;

function Add2(Value: Integer);
begin
  Result:= Add(Value,2);
end;

Soweit so gut.

Wie stelle ich aber sicher, dass das Add2 immer noch das tut was es soll ?
Es könnte ja jemand die Add verändern.

Das stellen Unit-Tests sicher.


Und was die Komplexität betrifft.
Ein komplexes Problem wird in kleinere Einheiten unterteilt, die einzeln getestet werden.
Natürlich muss auch das Gesamt-Problem getestet werden.

Das schöne am Unit-Test ist, dass du gezwungen wirst, testbaren Code zu schreiben.
Eine Button1Click-Funktion in einem Form darf ebend keinen Code enthalten,
sondern nur (externe) Funktion aufrufen, die völlig separat ist
und damit auch ohne das Form getestet werden kann.


Heiko

Heiko

[Assarbad]

Zitat:

Zitat von mjustin (Beitrag 1058044)

Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

Dann ist der Bug formal noch immer im Programm und nicht im Test. Denn das Programm hat sicherzustellen, daß alle benötigten Ressourcen für eine Operation verfügbar sind. Zugegeben, evtl. müßte man den Test dann anpassen um auf die entsprechende Meldung zu reagieren, aber die Bringschuld liegt m.E.n. beim Programm.

[Phoenix]

Das Beispiel von hoika ist genial.
Unit-Tests sind dafür da sicherzustellen, dass alles was von den Tests abgedeckt wird und vorher ging, auch nach beliebigen Änderungen hinterher auch noch geht - oder Dich direkt darauf hinweist das etwas jetzt anders ist und Du darauf noch reagieren musst.

Wie oft macht man an Stelle A etwas und später fällt jemandem auf, dass an Stelle Q irgendwas nicht mehr funktioniert (durch Seiteneffekt der Änderung an A). Sowas decken die Unittests bei guter Abdeckung sofort auf und sparen dadurch massiv Zeit (Fehlersuche, wieder reindenken, nach der Änderung manuell alles durchtesten, wieder was vergessen, wieder später erneut suchen...).

[mjustin]

Zitat:

Zitat von Assarbad (Beitrag 1058073)

Zitat:

Zitat von mjustin (Beitrag 1058044)

Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

Dann ist der Bug formal noch immer im Programm und nicht im Test. Denn das Programm hat sicherzustellen, daß alle benötigten Ressourcen für eine Operation verfügbar sind. Zugegeben, evtl. müßte man den Test dann anpassen um auf die entsprechende Meldung zu reagieren, aber die Bringschuld liegt m.E.n. beim Programm.

So meinte ich das auch, der Testlauf von TestComplete schlägt fehl, wenn die angenommene Fehlerfreiheit der Benutzeroberfläche nicht besteht. Ein "Test der fehlschlägt" ist aus Sicht der QA ein erfolgreicher Test, denn man hat einen Fehler gefunden. :)