Softwaretesting in Delphi

**Angel4585**

Guten Morgen!

Ich muss gestehen, ich habe bisher eher so drauflos programmiert und zumindest in Delphi nichts mit Unit-Tests am Hut gehabt.
Unit-Tests kenne ich bisher nur aus Java, C# und C++. Dementsprechend waren auch öfter mal Fehler in der Software die man halt übersehen hat.
Besonders für die Regressionstests fehlen mir die jetzt.

Wie ich in Delphi Unit-Tests erstelle ist eigentlich kein Problem, gibt ja auf der Tool-Palette ne Vorlage für Testprojekt und Testfall, die Frage is eher: Was teste ich genau?

Meine Anwendungen sehen oft so aus, dass ich ein Formular habe, ein Datenmodul und darauf dann TTables (bisher für BDE, in Zukunft TSQL... und Firebird) und TDataSourcen.
Unit-Tests habe ich bisher so verstanden, dass ich die für eigene Klassen verwende. In Delphi - bzw. in solchen Datenbankanwendungen - habe ich aber recht selten eigene Klassen die ich testen könnte. Ausser man bezeichnet die eigene GUI auch als eigene Klasse. Was testet man also?

Eigentlich sollte man ja alles testen. Also GUI und Datenbankzugriff.
Bei komplexeren Algorithmen gibt es ja wieder eigene Klassen die man testen kann.

Was testet man aber an ner GUI? Ob die Buttons am rechten Fleck liegen?
Und was testet man an der Datenbank? Ob alle Felder da sind die gebraucht werden?
Gibt es eigentlich auch Mocks für Delphi?
Gibt es zusätzliche Testframeworks die man dazukaufen sollte?

Ich arbeite mit Delphi 2010 Prof. und habe irgendwie Probleme mich beim Thema Testing zurecht zu finden, auch weil ich es wohl nie richtig mit Delphi gelernt habe. Ich wäre sehr dankbar, wenn ich Tipps zu dem Thema bekommen könnte.

**jaenicke**

Zitat von Angel4585:

Ausser man bezeichnet die eigene GUI auch als eigene Klasse. Was testet man also?

Wir benutzen dafür TestComplete.

http://smartbear.com/products/qa-too...-testing-tools
Das setzt dann die Datenbank auf einen definierten Anfangszustand, klickt sich durch die GUI wie ein Benutzer auch, nur schneller, prüft die Ergebnisse, usw.

Zitat von Angel4585:

Also GUI und Datenbankzugriff.
Bei komplexeren Algorithmen gibt es ja wieder eigene Klassen die man testen kann.

Das Zusammenspiel zwischen den einzelnen Komponenten zu testen nennt man Integrationstests.
Und es macht auch durchaus Sinn die Datenbankkomponenten selbst mit zu testen. Der Fehler im TClientDataSet, bei dem bei XE5 vor dem Update Locate nicht mehr funktionierte, wäre bei uns ohne Tests kaum so schnell gefunden worden.

Zitat von Angel4585:

Gibt es eigentlich auch Mocks für Delphi?

Ja, dafür findest du z.B. von Nick Hodges viel Material:

https://code.google.com/p/delphi-spring-framework/

http://www.nickhodges.com/page/Depen...on-Series.aspx

**mjustin**

Zitat von Angel4585:

Unit-Tests habe ich bisher so verstanden, dass ich die für eigene Klassen verwende. In Delphi - bzw. in solchen Datenbankanwendungen - habe ich aber recht selten eigene Klassen die ich testen könnte. Ausser man bezeichnet die eigene GUI auch als eigene Klasse. Was testet man also?

Unittests sind nicht speziell für Klassen gedacht. Man kann alle Funktionen und Prozeduren damit testen, auch solche die global definiert sind. Wenn man einen Testcase selbst statt über den Wizard erstellt kann man beliebige Tests hinzufügen.

Im Prinzip tested man Code so wie man Zähne putzen sollte: alle die, die man behalten möchte

Viele Entwickler beginnen auch mit dem Schreiben der Tests, bevor die Funktion programmiert wird ("Testgetriebene Entwicklung"). Tests schreiben und Funktionen erstellen gehen dann Hand in Hand.

Tests eignen sich oft auch als erstklassige Dokumentation, da sie zeigen, wie eine Funktion oder Prozedur benutzt wird, welche Vor- und Nachbedinungen (z.B. Initialisierungen, Setzen von Properties) sie erfordern, und welche Exceptions erwartet werden (letzteres wird in DUnit über "ExpectedException" unterstützt).

p.s. Lesetipp für lange Winterabende: "xUnit Test Patterns: Refactoring Test Code" von Gerard Meszaros

**rweinzierl**

Ich habe lezte Woche den Moderator eines Workshops gefragt wie Sie Test schreiben, seine Antwort fand ich gut.

Test werden im 4 Augen Prenzip geschrieben, dann macht das ganze Sinn.

Beim eigenen Code fällt es mir auch schwer die richtigen Testfälle zu definieren, aber wenn der Entwickler einen Kollegen erklären muss was er macht die Dokumentation nochmals durchgeht dann können durchaus sinnvolle Tests entwickelt werden.

Zitat von jaenicke:

Zitat von Angel4585:

Gibt es eigentlich auch Mocks für Delphi?

Ja, dafür findest du z.B. von Nick Hodges viel Material:

https://code.google.com/p/delphi-spring-framework/

http://www.nickhodges.com/page/Depen...on-Series.aspx

Finde da nichts über Mocking, nur DI und Grundlagen, wie man Klassen schreibt, die ohne Mocking testbar sind. Aber vermutlich bin ich blind.

**jaenicke**

Hmm, ok, ich habe das nun auch vorhin im Büro nicht genau angeschaut, da hast du Recht. Bei den Themen hätte ich gedacht es sei dabei.
Dann eben hier:

http://nickhodges.com/post/Delphi-Mocks-The-Basics.aspx

https://github.com/VSoftTechnologies/Delphi-Mocks