Projekt mit Unit-Tests aufsetzen

[Jumpy]

Hallo,

weil bei uns weder Unit-Tests geschweige denn TDD ein Thema sind, will ich mich zuhause ein bißchen damit beschäftigen und les mich gerade ein. Zur Übung möchte ich auch ein kleines Projekt mit TDD verwirklichen und habe schon beim aufsetzen des Projektes die erste Frage:

Wie setzt man so ein Projekt auf, sprich, wo packt man seine Units hin? Sind die Tests (das Testprojekt) und das eigentliche Projekt alle in einem Ordner?
Oder hab ich einen Testordner, wo ich meine Testsunits und meine zukünfigen Klassen-Units habe, quasi eine Werkstatt, und einen Ordner für mein eigentliches Projekt, wo ich die "fertigen und mit Prüfsiegel getesteten Units" rüberkopiere? Und Wenn ich eine Unit ändere, mach ich das in der Werkstatt und kopiere sie dann wieder in mein Projekt?

Und dann nochmal die Frage nach den Interfaces. Was ich bisher so gelesen habe (habe erst gerade angefangen, z.B hier http://wiki.lazarus.freepascal.org/fpcunit) werden mit den Unit-Tests doch Klassen getestet? Oder ist das nur in den Anfänger-Tutorials so? Weil ich doch meine sonst in Threads hier gelesen zu haben: Gegen Interfaces kann man besser testen usw.

[Klaus01]

Hallo,

ein kleiner Einstieg.

Wenn ich mich richtig entsinne, sollten laut "Uncle Bob" die Test- und Produktivsourcen im gleichen Verzeichnis liegen.

Grüße
Klaus

[CarlAshnikov]

Hallo,

ich verstehe deinen Werkstattvergleich irgendwie nicht. Wozu mehrere Exemplare der gleichen Datei haben? Da deine Tests ständig laufen sollten, müsstest du immer die Dateien herumkopieren. Ich denke so ist das nicht gedacht.

Wo du die Test-Sourcen speicherst ist denke ich nicht wichtig, solange du damit zurecht kommst und die Test-Units den Pfad der zu testenden Units kennen. Eine Möglichkeit ist es in einer Projektgruppe das zu testende Projekt und das Testprojekt zusammen zu fassen.

Im Prinzip testet man immer Objekte weil irgendo muss ja das Interface oder eine Methode implementiert sein die du testen willst. Mal davon abgesehen wenn du Prozeduren testest die keinem Objekt zugeordnet sind. Interfaces zu verwenden hilft dir vielleicht dahingehend, dass du dich an keiner Implementierung orientierst wenn du den Test schreibst. Außerdem kannst du dir daraus Mocks / Stubs erzeugen lassen wenn du ein Objekt isoliert testen willst.

[mjustin]

Zitat:

Zitat von CarlAshnikov (Beitrag 1267516)

Hallo,

ich verstehe deinen Werkstattvergleich irgendwie nicht. Wozu mehrere Exemplare der gleichen Datei haben? Da deine Tests ständig laufen sollten, müsstest du immer die Dateien herumkopieren. Ich denke so ist das nicht gedacht.

Es ist bei modularer Entwicklung gängige Praxis, in einem Entwicklungszweig zu arbeiten, der als "unstabil" angesehen wird und dann nach Abschluss eines Meilensteines die daraus entstehenden Dateien als "stabile" Version davon getrennt abzulegen, um aus Projekten nur auf diese stabilen Versionen zuzugreifen.

Bei Projekten die nicht modular aufgebaut sind, ist das natürlich nicht notwendig - da können Tests und Projektsourcen in einem Verzeichnis, quasi als ein einziger großer Klotz ('Monolith'), bearbeitet werden.

[CarlAshnikov]

Für mich hatte es sich so gelesen als würde er seine Dateien in die Werkstatt kopieren dort testen / bearbeiten und sie danach wieder raus kopieren. Zu eine Feature-Branch oder ähnlichem sollten aber die Tests ebefalls gehören, weil diese sich je nach Anforderung des Meilensteins auch ändern können. Meiner Meinung nach sollten die Tests dann genauso modular sein wie die Anwendung auch, sonst kommt man nicht zurecht. Alles in einem Ordner zu haben ist ab einer gewissen Größe auch bei monolitischen Systemen nicht übersichtlich.

[Jumpy]

Zitat:

Zitat von CarlAshnikov (Beitrag 1267516)

ich verstehe deinen Werkstattvergleich irgendwie nicht. Wozu mehrere Exemplare der gleichen Datei haben? Da deine Tests ständig laufen sollten, müsstest du immer die Dateien herumkopieren. Ich denke so ist das nicht gedacht.

Wenn man das so formuliert, mach das tatsächlich nicht viel Sinn. Zumindest auf ein Projekt bezogen. Hier macht ein Projektordner mit Test- und Hauptprojekt zusammen wahrscheinlich wirklich mehr Sinn, denn Test und Projekt gehören ja irgendwie auch zusammen.

Was ich mir aber vorstellen könnte ist ein separat gepflegter Bereich an wiederverwertbaren Klassen, die man in verschiedenen Projekten immer mal wieder brauchen kann. Hier wäre dann die Frage, ob ich einfach den Pfad zu diesem "Klassen-Sammlungs-Ordner" im konkreten Projekt mit angebe, oder jedesmal eine der Standard-Klassen in den konkreten Projektordner kopiere, wenn ich sie brauche. Letzteres hätte mMn den Nachteil, das diese Klasse im konkreten Projekt dann evtl. nicht mehr auf dem neusten Stand ist.
Wobei man dann natürlich umgekehrt argumentieren kann, dass man in Projekt X die Standardklasse Y auch nur in der Version braucht, in der sie da gerade drin ist. Aber damit landet man dann irgendwie bei der Versionsverwaltung was ja wieder ein eigenes Thema ist.

[Lemmy]

Zitat:

Zitat von Klaus01 (Beitrag 1267515)

Hallo,
ein kleiner Einstieg.

Super wenn Fragen beantwortet werden ohne dass man sie stellen muss :-) So was habe ich die Tage gesucht....

[Sir Rufo]

Zitat:

Zitat von Jumpy (Beitrag 1267532)

Was ich mir aber vorstellen könnte ist ein separat gepflegter Bereich an wiederverwertbaren Klassen, die man in verschiedenen Projekten immer mal wieder brauchen kann. Hier wäre dann die Frage, ob ich einfach den Pfad zu diesem "Klassen-Sammlungs-Ordner" im konkreten Projekt mit angebe, oder jedesmal eine der Standard-Klassen in den konkreten Projektordner kopiere, wenn ich sie brauche. Letzteres hätte mMn den Nachteil, das diese Klasse im konkreten Projekt dann evtl. nicht mehr auf dem neusten Stand ist.
Wobei man dann natürlich umgekehrt argumentieren kann, dass man in Projekt X die Standardklasse Y auch nur in der Version braucht, in der sie da gerade drin ist. Aber damit landet man dann irgendwie bei der Versionsverwaltung was ja wieder ein eigenes Thema ist.

Genau, mit einer Versionsverwaltung ist das kein Problem, denn dort kann man Externals deklarieren, die dann mit zwei Klicks aktualisiert werden, oder auch auf einer bestimmten Revision festgehalten werden.

Diese Sammlungen/Bibliotheken sollten jeweils einen eigenen Unit-Test haben, mit denen man dann die Funktionsweise testen kann.

[hoika]

Hallo,

es gibt bei dem Ort der Tests 2 Möglichkeiten:
1. in der gleichen Datei für die Klasse TMyClass eine Klasse TMyClass_Test
2. pro Unit eine eigene Unit (Unit MyUnit1 -> MyUnit1_Test).

Wir benutzen bei uns Variante 2.
Hat einfach pragmatische Gründe.
Ich will in der Versionsverwaltung Methoden und Methoden-Tests nicht in einer Datei haben/Revision haben.

Gemeinsam verwendete Klassen kommen in ein eigenes Repository.
Die Dateien liegen an einer einzigen Stelle, kopieren ? Oh Gott, nein! ;)
Mit Sicherheit wird mal was vergessen, und dann ist der Ärger gross.

DUnit benutzt keine Interfaces, sondern von einer Basisklasse abgeleitete Klassen,
du selbst kannst natürlich in den deinen eigentlichen Tests Interfaces benutzen.

Benutzt du in deinem eigentlichen Programm Interfaces,
ist es klug, dass auch in den Tests zu machen.

Delphi-Quellcode:

unit MyUnit1_Test;

interface

type
  TMyClass_Test = class(TTestCase)
    published
      procedure Test1;
  end;

implementation

...

begin
  TestFramework.RegisterTest(TMyClass_Test.Suite);
end.

Heiko

[Stevie]

Zitat:

Zitat von Jumpy (Beitrag 1267514)

Und dann nochmal die Frage nach den Interfaces. Was ich bisher so gelesen habe (habe erst gerade angefangen, z.B hier http://wiki.lazarus.freepascal.org/fpcunit) werden mit den Unit-Tests doch Klassen getestet? Oder ist das nur in den Anfänger-Tutorials so? Weil ich doch meine sonst in Threads hier gelesen zu haben: Gegen Interfaces kann man besser testen usw.

Natürlich werden Klassen (bzw Implementierungen) getestet. Interfaces sind Abstraktionen und Abstraktionen kann man nicht testen. Ein Interface besitzt ja keinen ausführbaren Code, sondern nur die Klasse, die das implementiert.

Was du wahrscheinlich schon öfter gelesen hast, ist der Hinweis, gegen Interfaces (bzw Abstraktionen) zu programmieren. Ich konsumiere also in meiner Klasse TToaster nicht TEnergieversorgung sondern IEnergieversorgung. Somit kann ich in einem Test für meinen Toaster alle Abhängigkeiten (z.B. IEnergieversorgung) ausmocken. Das Stichwort heißt hier: lose Kopplung
Wenn ich das nämlich nicht mache, sondern überall mit den direkten Klassen (Implementierungen) arbeite, dann hab ich keine Nähte, und im schlimmsten Fall in meinem Toaster Test am Ende auch noch TBraunkohlekraftwerk drin, weil alles festverdrahtet ist.

[Jumpy]

Ach so. Jetzt versteh ich glaub ich wie das gemeint ist. Innerhalb meiner Klassen benutze ich Interfaces um auf andere Klassen zuzugreifen, so dass ein Test der zu testenden Klasse an dieser Stelle irgendeine Mock-Klasse rüberschieben kann, die das gleiche Interface benutzt.

Im Test selber wird dann die zu testende Klasse wirklich als Klasse erzeugt und angesporchen, sprich dafür werden die Interfaces nicht benutzt?

[Stevie]

Zitat:

Zitat von Jumpy (Beitrag 1267663)

Im Test selber wird dann die zu testende Klasse wirklich als Klasse erzeugt und angesporchen, sprich dafür werden die Interfaces nicht benutzt?

Über die Interfaces wird eine Austauchbarkeit der verschiedenen Implementierungen möglich. Toasterbeispiel:

Delphi-Quellcode:

type
  TToaster = class
  public
    constructor Create(const powerSupply: IPowerSupply);
  end;

In einem Unittest kannst du nun, um deinen Toaster zu testen, ein Mock für IPowerSupply übergeben, womit du also nicht die richtige Implementierung davon benötigts (denn du willst ja TToaster testen und nicht was anderes). Über einen Mock kannst du auch sicherstellen, dass der TToaster die entsprechenden Methoden von IPowerSupply aufruft, die gemäß Spezifikation erwartet werden.

Zu dem Thema noch ein interessantes Video

[Jumpy]

Zitat:

Zitat von Stevie (Beitrag 1267665)

Delphi-Quellcode:

type
  TToaster = class
  public
    constructor Create(const powerSupply: IPowerSupply);
  end;

In einem Unittest kannst du nun, um deinen Toaster zu testen, ein Mock für IPowerSupply übergeben, womit du also nicht die richtige Implementierung davon benötigts (denn du willst ja TToaster testen und nicht was anderes). Über einen Mock kannst du auch sicherstellen, dass der TToaster die entsprechenden Methoden von IPowerSupply aufruft, die gemäß Spezifikation erwartet werden.

Das hatte ich schon so verstanden. Ich dachte (wahrscheinlich zu kompliziert) eher daran: Wie teste ich, ob eine Klasse, die ein bestimmtes Interface implementiert, das richtig implementiert?

Delphi-Quellcode:

type
  TMyClass = class (TInterfacedObject,IMyInterface)
    public
      procedure IrgendeineProzedurDesInterfaces();
   end; 

type
  TMyClass_Test = class(TTestCase)
    published
      procedure TestInterface;
  end;

Wie müsste TestInterface aussehen? Teste ich darin einfach die Prozefur IrgendeineProzedurDesInterfaces() der Testklasse, sprich interessiert mich an der Stelle gar nicht, das TMyClass IMyInterface implementiert?

P.S.: Danke für den Video-Link. Schau ich mir heut Abend mal an.

[Stevie]

Zitat:

Zitat von Jumpy (Beitrag 1267727)

Wie teste ich, ob eine Klasse, die ein bestimmtes Interface implementiert, das richtig implementiert?

So, wie man auch alle anderen Dinge nach dem "Arrange, Act, Assert"-Prinzip testet.

Wobei das in deinem Beispiel etwas komplexer werden kann, denn deine Methode hat weder Eingabe, noch Ausgabe.
Also kann sie nur einen internen Status von TMyClass verändern. Also kann Arrange und Assert etwas mühsam werden,
wenn diese nicht von außen zugänglich sind oder nur über Umwege.
Das läuft dann aber wieder mal in die "wie designe ich Code, der gut testbar ist" Richtung, was in dem Video gezeigt wird.