JUnit

[Thaitanium]

Moin,

ich habe drei Testmethoden innerhalb einer Testklasse. Wenn die erste Methode fehlschlägt müssen die anderen zwangsläufig auch fehlschlagen weil sie aufeinander aufbauen. Sprich wenn die erste Methode fehlschlägt sollen die anderen gar nicht erst weiter ausgeführt werden. Gibt es eine simple Methode dies zu realisieren?

Gruß
Thai

 

[Trolllllll]

Have a look http://www.java-forum.org/java-basics-anfaenger-themen/144293-junit.html

 

[kama]

Hi,

mithilfe von TestNG läßt sich das Problem recht einfach lösen...

@Test
public void serverStartedOk() {}
 
@Test(dependsOnMethods = { "serverStartedOk" })
public void method1() {}

Dabei ist aber zu beachten, dass Du wohl schon im Bereich der Integrations Tests bist...da Unit Test per Definition unabhängig voneinander sein müssen.

Gruß
Karl-Heinz Marbaise

 

[Thaitanium]

OK, tut mir Leid bin noch Anfänger.
Ist TestNG dann auch fürs Unit testen oder wie darf ich Deine "Warnung" verstehen?
Ich bin in JUnit gelandet a) weil ich das aus der Uni kenne ^^ und b) weil Selenium mir das vorgeschlagen hat.

Und zu dem Link von Trollllllll.
Ich verstehe den Thread bzw. das Problem glaub ich nicht ganz.
Denn wenn er die Tests in verschiedenen Klassen hat, kann er doch die Reihenfolge in der Testsuite klasse bestimmen. Wie gesagt hab das ganz nich so ganz verstanden und bin auch noch Anfänger 🙂

Zu meinem Problem:
Ich simuliere mit Selenium Uservehalten auf einer Seite. In meinem konkreten fall gerade habe ich das folgendermaßen gegliedert:
1. Testmethode: Seite aufrufen.
2. Testmethode:Einloggen/durch die Seite navigieren.
3. Testmethode: Den Inhalt eines bestimmten Feldes prüfen.

So wenn nun die Seite nicht aufgerufen werden kann, funktioniert auch das Einloggen/Navigieren nicht. Sprich die ganze Testklasse soll abbrechen. Und sowas ist mit JUnit nicht möglich?
Also soll ich z.B.: auf TestNG ausweichen? Oder ist das auch eher eine Notlösung? Wie sollte ich denn sonst daran gehen?

Danke schonmal im Voraus
Thai

 

[tfa]

Mit TestNG ist das möglich. Die Dokumentation findest du hier: TestNG

Deine Beschreibung lässt vermuten, dass du keine Unit-Tests hast. Unit-Tests testen wirklich nur ein isoliertes Stück Software (z.B. eine Methode). Wenn Sessions, Logins usw. ins Spiel kommen (und die nicht gemockt werden), sind wir schon bei Integrations- oder sogar Systemtests. Um die durchzuführen kann man sicherlich auch JUnit benutzen (meiner Meinung nach ist es ein Fehler von JUnit, dass es JUnit heißt), TestNG bietet hierzu aber deutlich mehr Möglichkeiten.

 

[Thaitanium]

Okay,
danke für die klare antwort.

Gruß
Thai

 

[maki]

(meiner Meinung nach ist es ein Fehler von JUnit, dass es JUnit heißt)

.. genau dieser Fehler führt seit Jahren zu eigentlich überflüssigen Missverständnissen, DIskussionen und Ausführungen.

..weil sie aufeinander aufbauen...

Würde mir wirklich nochmal überlegen ob du dass so machen willst..

Inwiefern hängen die Tests voneinander ab?
Erzeugen die Tests die zuerst laufen etwa Testdaten in der DB für die Tests die danach laufen?
Das wäre jedenfalls keine so gute Idee IMHO.

Nachtrag:
Lese gerade dass es um einen Selenium Test und Login handelt.. insofern den letzten Absatz bitte ignorieren.

 

[Akeshihiro]

Warum soll das ein Fehler sein? Ich wüsste nicht, dass JUnit jemals für Vergewaltigungen der heutigen Art gedacht war, sondern einfach nur für Unit-Tests. Da kann JUnit doch nix dafür, dass Leute versuchen es als eine Art Betriebssystem zu verwenden, das alles können soll.

 

[tfa]

Warum soll das ein Fehler sein? Ich wüsste nicht, dass JUnit jemals für Vergewaltigungen der heutigen Art gedacht war, sondern einfach nur für Unit-Tests. Da kann JUnit doch nix dafür, dass Leute versuchen es als eine Art Betriebssystem zu verwenden, das alles können soll.

Warum sollte man JUnit nicht für Integrationstests benutzen dürfen? Wenn man unter Eclipse-PDE entwickelt, hat man sogar keine andere Wahl als JUnit.
Außerdem bietet JUnit selbst die Möglichkeit, ein Timeout für Tests anzugeben. Wozu sollte man das bei ausschließlich Unittests brauchen?

 

[Akeshihiro]

Ich hab nie gesagt, dass man das nicht darf. Ich hab nur gesagt, dass das ursprünglich sicherlich nicht für sowas vorgesehen war, zumal es zu der Zeit nichts vergleichbares gab. Der Name mag heute vielleicht nicht ganz passen, aber man darf nicht vergessen, dass JUnit in der heutigen Form viele Veränderungen mitgemacht hat und anfangs nicht so aussah. Zudem sehe ich auch einen Integrationstest als eine Art Unit-Test, nur ist die Unit dann etwas größer als nur eine Methode, das wars dann aber auch schon. Man hat nach wie vor eine Ausgangssituation X und will nach Abarbeitung unter bestimmten Rahmenbedingungen die Situation Y vorfinden.

 

[tfa]

Ich hab nie gesagt, dass man das nicht darf.

Dein "Ich wüsste nicht, dass JUnit jemals für Vergewaltigungen der heutigen Art gedacht war" ließ mich das denken.

Zudem sehe ich auch einen Integrationstest als eine Art Unit-Test, nur ist die Unit dann etwas größer als nur eine Methode, das wars dann aber auch schon.

Das finde ich überhaupt nicht. Unittest und Integrationstest sind schon grundlegend verschieden. Aber wie maki schon sagte, ist die Diskussion hierüber wohl überflüssig.

 

[maki]

Der Name mag heute vielleicht nicht ganz passen

Der Name hat auch früher schon nicht gepasst, denn Integrationstests konnte man schon immer damit schreiben, nicht nur Unittests, und die Unterschiedung zwischen Unittest und Integrationtest ist älter als JUnit.

Unittests sind nunmal nicht dasselbe wie Integrationstests, per Definition, der Name "JUnit" verwirrt genug Anfänger in dem Bereich.

 

[Akeshihiro]

Unittests sind nunmal nicht dasselbe wie Integrationstests, per Definition, der Name "JUnit" verwirrt genug Anfänger in dem Bereich.

Ja gut, das ist schon richtig. Aber naja, was sollen Anfänger auch mit Integrationstests?

Ich werfe da mal Spock noch mit rein. Damit schreibt man Spezifikationen, das ist dann vielleicht etwas eindeutiger. Und die Specs zu schreiben ist, wie ich finde, auch sehr viel einfacher, aussagekräftiger und vor allem lesbarer.

 

[darekkay]

Ja gut, das ist schon richtig. Aber naja, was sollen Anfänger auch mit Integrationstests?

Siehe dieser Thread 😉
Gerade als Anfänger gibt es meist gar keine Schichten-Trennung: da gibt's die MainView-Klasse, die DB-Aufrufe macht etc. Und wenn man dort etwas testen möchte, wird es automatisch ein Integrationstest - obwohl man "nur eine Methode testet".

 

[faetzminator]

Es ist aber ganz klar, wo mit JUnit die Grenzen liegen. Man kann keine Abhängigkeiten zwischen den Test haben, auch keine Reihenfolge definieren. Dann gibts noch die 2 @Before... und die anderen bekannten Annotationen. Nicht mehr und nicht weniger.

 

[maki]

Ja gut, das ist schon richtig. Aber naja, was sollen Anfänger auch mit Integrationstests?

Eben, behaupte mal der Großteil der Anfänger schreibt Integrationstests ohne es zu wissen (DAO werden mit DB getestet, Systemgrenzen wie zB. zum Dateissystem werden überschritten) und kommt dann zur falschen Einsicht "Unittests sind komplex", von Mockobjekten haben die meisten dann noch nix gehört um Abhängigkeiten zu ersetzten.

Ich habe hier in der Arbeit mindestens 2 mal pro Woche eine Diskussion mit Entwicklern über ihre "Tests", jedesmal dasselbe, "meine JUnittests ...." ist so eine Aussage, die nix aussagt, meine Frage dann: "Unit- oder Integrationstests?", Antwort: "mit JUnit halt..."

Es ist aber ganz klar, wo mit JUnit die Grenzen liegen. Man kann keine Abhängigkeiten zwischen den Test haben, auch keine Reihenfolge definieren. Dann gibts noch die 2 @Before... und die anderen bekannten Annotationen. Nicht mehr und nicht weniger.

Sehe ich nicht so, JUnit macht gar keine Einschränkungen, man kann ja seine statische Testsuite definieren inkl. Tests und deren Reihenfolge.

Man kann also auch Abhängigkeiten zwischen Tests damit festlegen (ist aber schon ein Fehler an sich in Unittests, oft auch in Integrationstests), JUnit eignet sich für Unit- und Integrationstests gleichermassen IMHO, sehe da keine Einschränkung von JUnit.

 

[faetzminator]

Ich habe hier in der Arbeit mindestens 2 mal pro Woche eine Diskussion mit Entwicklern über ihre "Tests", jedesmal dasselbe, "meine JUnittests ...." ist so eine Aussage, die nix aussagt, meine Frage dann: "Unit- oder Integrationstests?", Antwort: "mit JUnit halt..."

Kenn ich, kenn ich.

Sehe ich nicht so, JUnit macht gar keine Einschränkungen, man kann ja seine statische Testsuite definieren inkl. Tests und deren Reihenfolge.

Das wär dann einfach auf Klassenebene? Hab anno dazumal eine Suite geschrieben, aber seit Maven-Builds mit Jenkins und Sonar nie wieder benötigt 🙂

 

[maki]

Ja, sozusagen auf Klassenebene..

Meine Testsuites werden auch dynamisch von Surefire zusammengestellt 🙂

 

[Thaitanium]

Schön dass ich hier so eine rege "diskussion" entfachen konnte. 😀
Ich werde dann meine Tests jetzt bischen umbasteln und mit TestNG arbeiten.
Damit würde ich ja auch relativ schnell Reports erzeugen können oder!? 😉