8
Zum Beispiel:Ist es eine schlechte Idee, Tests zu erstellen, die innerhalb einer Testvorrichtung aufeinander angewiesen sind?
// NUnit-like pseudo code (within a TestFixture)
Ctor()
{
m_globalVar = getFoo();
}
[Test]
Create()
{
a(m_globalVar)
}
[Test]
Delete()
{
// depends on Create being run
b(m_globalVar)
}
... oder ...
// NUnit-like pseudo code (within a TestFixture)
[Test]
CreateAndDelete()
{
Foo foo = getFoo();
a(foo);
// depends on Create being run
b(foo);
}
... ich mit der später würde und unter der Annahme, dass die Antwort auf meine Frage ist:
Nein, zumindest nicht mit NUnit, weil according to the NUnit manual:
Der Konstruktor sollte keine Nebenwirkungen haben, da NUnit die Klasse mehrere Tim erstellen kann es im Laufe einer Sitzung.
... kann ich auch davon ausgehen, dass es generell eine schlechte Praxis ist? Da Tests in der Regel separat ausgeführt werden können. So kann das Ergebnis von Create niemals durch Löschen bereinigt werden.
ich damit einverstanden, aber alle TestNG http://testng.org/doc/index.html nicht sehen, was eine Verbesserung gegenüber jUnit in vielerlei Hinsicht, sondern ermöglicht auch abhängig Tests - vor allem http: // beust.com/weblog/2004/02/08/junit-pain/für die Begründung der Authorin – Mark
@Mark, TestNG kenne ich nicht, danke für den Link. –
@Mark: Die Argumentation in der zweiten Link ist tatsächlich trügerisch. Bei Komponententests sollte die Datenbank trotzdem gespottet werden, so dass die Kosten für die Einrichtung und den Abbau von Ressourcen ignoriert werden, und für Integrationstests können Sie sich die Kosten leisten (Sie müssen auch die Datenbank in einen bekannten Zustand versetzen und andere) solche Dinge, die in sich durchaus einen Einfluss haben können). –