Gerätetest. Dateistruktur

Question

Ich habe eine C++ Legacy-Codebase mit 10-15 Anwendungen, die alle mehrere Komponenten teilen.

Während ich Unittests sowohl für gemeinsam genutzte Komponenten als auch für Anwendungen selbst eingerichtet habe, habe ich mich gefragt, ob es akzeptierte/übliche Dateistrukturen dafür gibt.

Da meine Komponententests mehrere Basisklassen haben, um projektspezifische/kundenspezifische Testeinstellungen zu vereinfachen, gibt es viele Dateien, die für alle Tests gemeinsam sind.

Für mich scheint es natürlich hier, ein neues Verzeichnis zu erstellen, das alle testbezogenen Dateien, Mocks usw. enthält - um alles zentralisiert zu haben und auch verwandte Definitionen aus den wichtigsten make-Dateien zu testen.

Auf der anderen Seite sehe ich, dass es üblich ist, die Testdateien zusammen mit den Code-Dateien zu haben, die sie testen.

Gibt es einen mehr oder weniger akzeptierten Weg, dies zu tun?

Answer 1

Aus den Augen, aus dem Sinn; Wenn Sie die Testdateien zusammen mit den Codedateien aufbewahren, ist es für die Entwickler offensichtlich, dass sie beim Aktualisieren einer Codedatei auch die Tests aktualisieren sollten.

Answer 2

Wie Sie bereits festgestellt haben, gibt es zwei gängige Methoden zum Suchen von Komponententestdateien: in der Nähe des zu testenden Implementierungscodes und in einer separaten Dateihierarchie. Die Wahl ist eine Frage dessen, was in Ihrer Organisation und Ihrem persönlichen Geschmack üblich ist.

In Bezug auf den Speicherort des allgemeinen Testcodes, organisieren Sie einfach Ihren Testcode, wenn Sie den Implementierungscode organisieren würden.

In Ihrem speziellen Fall, wenn eine Testinfrastruktur mehreren unabhängigen Komponenten gemeinsam ist, wäre es eine gute Idee, eine neue Komponente zu erstellen (nennen Sie es "testen"), von der andere Komponenten abhängig sind. anstatt Abhängigkeiten zwischen bestehenden Komponenten hinzuzufügen.

Answer 3

ich in der Regel einen solchen Code in einer Dateistruktur organisieren, die (in einem einfachen Fall) wie folgt aussieht:

apps 
    app1 
     app1module1 
     app2module2 
     app1tests 
    app2 
     app2module1 
     app2tests 
components 
    comp1 
     comp1module1 
     comp1module2 
     comp1tests 
common_test_stuff 

Es gibt keine einzige richtige Weg, dies zu tun, aber dies scheint eine gängige Praxis zu sein, dass hält Produktion und Testcode getrennt und versucht, das out-of-mind Problem (von zac erwähnt) zur gleichen Zeit zu entfernen.

Answer 4

Halten Sie den Testcode in der Nähe des Produktcodes und ordnen Sie Ihr Makefile (oder was auch immer Sie verwenden) so, dass die Tests zur gleichen Zeit wie der Test kompilieren, um sie sichtbar zu machen, besonders wenn nicht jeder in der Team schreibt Tests.