Wohin mit wiederverwendbaren Testmethoden, die in mehreren Grails-Testklassen verwendet werden

Question

Ich muss oft die gleichen Teststrukturen für verschiedene Testfälle einrichten. Daher habe ich eine TestService-Klasse erstellt, die mehrere öffentliche Methoden für die Testklassen enthält.

Ich vermute, dass dies nicht der beste Ort ist, um sie zu setzen, da TestService auch bereitgestellt werden, obwohl nicht auf Produktion benötigt.

Wo würden Sie diese gängigen Testmethoden unterbringen? Gibt es dafür eine "beste Praxis"?

Answer 1

Die Art und Weise, wie ich es mache, ähnelt den obigen Antworten. Wenn ich eine MyDomain-Klasse habe, lege ich eine MyDomainTestHelper-Klasse in ein Testpaket. Die Hilfsklasse hat statische Methoden, die die fraglichen Domänenobjekte zurückgeben. Ich könnte also eine

static createTestMyDomain() {...}

die eine Instanz mit sinnvollen Standardwerten erzeugt und

static createTestMyDomain(String something)

damit ich etwas angeben kann und so weiter.

Sie sollten sie nicht in einen "Dienst" setzen, wie Sie erwähnt haben. Aber jeder Weg, den Sie DRY sein können, ist ein guter Weg.

Answer 2

Ich versuche, mich an die DRY Prinzip beim Schreiben von Tests so weit wie möglich zu berücksichtigen. Das zeigt sich vor allem auf zwei Arten:

1. Normalerweise implementiere ich eine TestData Klasse, die alle Daten, die ich in meine Tests einspeise, in statischen Eigenschaften speichert, um die Übersicht darüber zu behalten, welche Eingaben ich den Tests gebe, und um sicherzustellen, dass ich niemals unterschiedliche Eingaben mache, wenn ich dieselben beabsichtige. Diese Klasse befindet sich in einem Testprojekt oder in einer Klassenbibliothek, die nur von den Testprojekten referenziert wird.

2. Wenn ich feststelle, dass ich dieselben Auf- oder Abbau-Routinen in vielen Tests benötige, mache ich oft Gebrauch von der Vererbung - ich erstelle eine Basisklasse, von der die Testfixtures erben können und die alle gemeinsamen Aktionen enthält.

Fußnote: Ich entwickle fast ausschließlich in C#, aber ich glaube, dass diese Praktiken in jeder Sprache mit einem Test-Framework angewendet werden können.

Answer 3

Warum legst du sie nicht neben deine Klassenarbeiten? Üblicherweise wird der gesamte testbezogene Code in ein vom Quellverzeichnis getrenntes Verzeichnis (z. B. "test") gelegt. D.h. nicht nur die Testfälle selbst, sondern auch unterstützende Klassen, wie z.B. Utility-Methoden, Mock-Implementierungen usw.

Die Testfälle sollten in dasselbe Paket wie die von ihnen getestete Klasse aufgenommen werden (aber in ein anderes physisches Verzeichnis, wie oben erläutert). Eine Test-Utility-Klasse, die von mehreren Testfällen verwendet wird, sollte in einem gemeinsamen Utility-Paket abgelegt werden.