Wo liegt de Test Code !?

Schlangenmensch

Bei uns sieht es genauso aus, wie bei @Quiche-Lorraine

SoIntMan

Ok intereressant, ich sehe oft dass im productiv Code (Project) eine Test folder ist, in dem alles teste drin sind.. aber ich hätte auch persönlich so wie ihr das ausgelagert

Schlangenmensch

@SoIntMan Aufpassen beim Wording: die Software an der ich arbeite, würde man im Bereich des Management vlt. ein Projekt nennen. Im MS Visual Studio Sprech habe ich eine Solution mit vielen Projekten. Ein Projekt davon ist das Testprojekt, welches zu einer eigenständigen exe kompiliert wird.

In der Datenordnung sind die Testsourcen in einem Unterordner, wie alle anderen Teilprojekte der Software auch in ihrem jeweiligen Unterordner liegen.

SoIntMan

@Schlangenmensch sagte in Wo liegt de Test Code !?:

@SoIntMan Aufpassen beim Wording: die Software an der ich arbeite, würde man im Bereich des Management vlt. ein Projekt nennen. Im MS Visual Studio Sprech habe ich eine Solution mit vielen Projekten. Ein Projekt davon ist das Testprojekt, welches zu einer eigenständigen exe kompiliert wird.
In der Datenordnung sind die Testsourcen in einem Unterordner, wie alle anderen Teilprojekte der Software auch in ihrem jeweiligen Unterordner liegen.

Guten morgen, das habe ich verstanden danke. Ja ich arbeite auch mit VS .. und habe produktivcode und testcode in VS projekten gespittet..

Aber was sind die Vor- und Nachteile wenn ich splitte oder test code in extra "Tests" Folders auf der Ebene "src" folder erstelle?

Quiche Lorraine

@SoIntMan
Ich verstehe deine Frage nicht so ganz.

Ganz am Anfang hatte ich Testfunktionen in den Sourcen geschrieben und diese mittels Assertionen in den jeweiligen Main Funktionen überprüft.

Dann entdeckte ich Testprojekte und zog den kompletten Testcode in eigene Dateien im Testprojekt. Das hatte einige Vorteile:

Das Testprojekt prüft alle benutzten Quellen. Ich muss also nicht mehr alle Main Funktionen anfassen, sobald ich was ändere.
Der Testcode wurde stellenweise groß (> 1k LOC). Das möchte man nicht in den Sourcen haben.
Der Code prüfe ich für alle Builds (z.B. x64 Debug) und nicht alle Projekte unterstützen diese Builds.

Das Testprojekt ist mein zentraler Punkt wenn ich etwas "festklopfen" möchte.

Deswegen liegen alle Testdateien im Ordner des Testprojekts. In welchem Ordner ist fast egal, Hauptsache nicht mehr im Sourcen Ordner.

SoIntMan

@Quiche-Lorraine sagte in Wo liegt de Test Code !?:

@SoIntMan
Ich verstehe deine Frage nicht so ganz.
Ganz am Anfang hatte ich Testfunktionen in den Sourcen geschrieben und diese mittels Assertionen in den jeweiligen Main Funktionen überprüft.
Dann entdeckte ich Testprojekte und zog den kompletten Testcode in eigene Dateien im Testprojekt. Das hatte einige Vorteile:

Das Testprojekt prüft alle benutzten Quellen. Ich muss also nicht mehr alle Main Funktionen anfassen, sobald ich was ändere.
Der Testcode wurde stellenweise groß (> 1k LOC). Das möchte man nicht in den Sourcen haben.
Der Code prüfe ich für alle Builds (z.B. x64 Debug) und nicht alle Projekte unterstützen diese Builds.

Das Testprojekt ist mein zentraler Punkt wenn ich etwas "festklopfen" möchte.
Deswegen liegen alle Testdateien im Ordner des Testprojekts. In welchem Ordner ist fast egal, Hauptsache nicht mehr im Sourcen Ordner.

Ok verstanden, das beantwortet meine Frage. Ich meinte nur deswegen, weil ich oft sehe dass Leute in ihren Projekten "direkt" Test verzeichnisse haben.. aber vll. ist das auch Sprachabhängig wo es Sinn macht,

Leon0402

@SoIntMan sagte in Wo liegt de Test Code !?:

Ok verstanden, das beantwortet meine Frage. Ich meinte nur deswegen, weil ich oft sehe dass Leute in ihren Projekten "direkt" Test verzeichnisse haben.. aber vll. ist das auch Sprachabhängig wo es Sinn macht,

Vlt. kannst du mal erklären wie du das genau meinst. Ich denke hier ist ein bisschen VS Sprech mit drin mit den "Projekten" und zumindest ich weiß nicht so genau wie das funktioniert.

Also in C++ kenne ich es so:

my_project_folder

src
test

Allerdings sind die Sachen in Test dann eine eigene Executable (= eigenes Project in VS?). Also sprich, ist gegen den source code dann verlinkt. In Python macht man es i.d.R. genauso, da hat man allerdings ja keine Kompilierung. Und in vielen anderen Sprachen denke ich auch. Ausnahme ist vlt. Java. Die haben ja immer dieses Layout mit main / test folder für jedes package.

SoIntMan

@Leon0402 sagte in Wo liegt de Test Code !?:

Also in C++ kenne ich es so:
my_project_folder
src
test

ja aber in VS ist ein Project-folder == Projekt an sich. Also ist src und test code im selben projekt.

und dann macht man:

Productiv code:

my_project_folder
src

Test code:

my_project_folder_test
test

It0101

Dasselbe Projekt: ja
Derselbe Build: nein
Ansonsten mach ich es wie die Vorredner auch. Im Projektordner gibt es "src" und "test". Im Projekt kann ich beides bearbeiten aber unterschiedliche Builds auslösen.

SoIntMan

@It0101 sagte in Wo liegt de Test Code !?:

Dasselbe Projekt: ja
Derselbe Build: nein
Ansonsten mach ich es wie die Vorredner auch. Im Projektordner gibt es "src" und "test". Im Projekt kann ich beides bearbeiten aber unterschiedliche Builds auslösen.

jo verstehe, im VS solution and project style geht das "glaube" ich nicht..:)

Schlangenmensch

@SoIntMan Die VS Solution und Projektstruktur muss nicht der Ordnerstruktur entsprechen. Du kannst jedem Projekt in einer Solution sagen, woher es welche Source Dateien nehmen soll, und zu was das Projekt kompiliert werden soll.
Im Konfiguration Manager kann man auch einstellen, welche Projekte bei welchem Build mit welcher Konfiguration kompiliert werden sollen.

Die Ordnerstruktur ist bei uns gewachsen und sieht etwas vereinfacht so aus

root
  -> code
    ->src
       -> part a
       -> part b
       -> part c
       -> ...
       -> test
    -> bin
    -> build
  -> resources
  -> tools
  -> setup

Im Solutionexplorer in VS habe ich dann:

root
   -> part a
   -> part b
   -> part c
   -> ...
   -> test

VS ist da sehr frei, wie man die Dinge konfiguriert. Aber angenehmer ist es natürlich das von CMake oder so erledigen zu lassen.