# GUI erstellen um JUnit Tests auszuführen



## Hyperbeast (21. Okt 2016)

Hallo,

ich überlege grade ob es aus technischer Sicht möglich wäre eine GUI für meine Java Tests zu erstellen.

Der Benutzer wählt z.B. über Radio Buttons drei mögliche Testsuites aus und klickt auf einen Button "Testen". Anschließend werden die JUnit Tests im Hintergrund ausgeführt und im besten Falle wird eine ProgressBar mit aktuellem Fortschritt eingeblendet.

Hat jemand sowas schon mal gemacht bzw. seht ihr da Probleme in der Machbarkeit? Auf dem ersten Blick sehe ich hier zwar keine Fallstricke, möchte aber mal gerne erfahren wie ihr das sieht.

Gruß

Edit: So soll es aussehen ungefähr:
http://up.picr.de/27185406ix.jpg


----------



## mrBrown (21. Okt 2016)

Du meinst das, was aktuelle IDEs machen?


----------



## Hyperbeast (21. Okt 2016)

mrBrown hat gesagt.:


> Du meinst das, was aktuelle IDEs machen?


Ich arbeite mit Eclipse und dort gibt es sowas auch nicht... wie dem auch sei: Ich will diese GUI nicht für mich, sondern unseren Kunden in die Hand drücken, damit die von sich aus mal testen können. Da ein Kunde aber i.d.R. keine IDE hat brauche ich eine "stand-alone" GUI.


----------



## stg (21. Okt 2016)

Hyperbeast hat gesagt.:


> Ich will diese GUI nicht für mich, sondern unseren Kunden in die Hand drücken, damit die von sich aus mal testen können.



Vielleicht erklärst du mal etwas genauer, was du eigentlich vor hast. Denn entweder verstehe ich dich nicht richtig, oder dieses Vorhaben ist einfach sinnlos. Da kannst du dem Kunden auch genauso gut ein Stück buntes Papier in die Hand drücken, auf dem steht "alle Tests bestanden". Das kann er sich dann immer angucken, wenn ihm danach ist..


----------



## mrBrown (21. Okt 2016)

Hyperbeast hat gesagt.:


> Ich arbeite mit Eclipse und dort gibt es sowas auch nicht


Das würd mich sehr überraschen, wenn das nicht geht, alle anderen die ich kenne können das problemlos...




Hyperbeast hat gesagt.:


> Ich will diese GUI nicht für mich, sondern unseren Kunden in die Hand drücken, damit die von sich aus mal testen können. Da ein Kunde aber i.d.R. keine IDE hat brauche ich eine "stand-alone" GUI.



Möglich ist's, Tests mit JUnit per Code zu starten. Einfacher ist aber vllt, das Buildtool laufen zu lassen, und den generierten Report aufzuhübschen...

Allerdings sehe ich da die Sinnhaftigkeit nicht wirklich, den Kunden Test ausführen zu lassen (und schon gar nicht, jeden TestCase einzeln auswählen zu können)...


----------



## Hyperbeast (21. Okt 2016)

Ich habe das Gefühl das wir hier alle aneinander vorbei reden...




mrBrown hat gesagt.:


> Das würd mich sehr überraschen, wenn das nicht geht, alle anderen die ich kenne können das problemlos...


Du kannst auch direkt sagen, dass du das JUnit Plugin meinst, welches Testsuites ausführt. Und wenn es das nicht ist, kannst du auch etwas klarer indem werden, was du eigentlich meinst. Sonst reden wir hier ja im Kreis die ganze Zeit...



stg hat gesagt.:


> Vielleicht erklärst du mal etwas genauer, was du eigentlich vor hast


Also: Was ich möchte ist eine *seperate *Anwendung (mit GUI) die völlig losgelöst von Eclipse oder sonst was gestartet werden kann. Also eine executable jar (nennen wir sie mal Tests.jar). Diese Tests.jar soll dann vom Kunden gestartet werden können. Dadurch poppt ein Fenster auf (wie er von mir im Post#1 skizziert wurde) und durch ein Klick auf "Start" werden JUnit Tests getriggert.  

Wieso wir ihm nicht ein Blatt Papier geben worauf steht "Test bestanden" ist doch eigentlich völlig irrelevant. Ich wollte nur wissen ob sowas technisch möglich wäre, weil das Programm ja quasi "interne" JUnit Tests ausführt. Wenn du wirklich dran Interesse hast zu wissen was der Sinn dahinter ist, kläre ich dich gerne darüber auf. Ich wollte jetzt erstmal nur nicht so weit ausholen für diese Frage.



mrBrown hat gesagt.:


> jeden TestCase einzeln auswählen zu können


 Es sind nicht die einzelnen Testcases sondern Testsuites...


----------



## mrBrown (21. Okt 2016)

Hyperbeast hat gesagt.:


> Du kannst auch direkt sagen, dass du das JUnit Plugin meinst, welches Testsuites ausführt. Und wenn es das nicht ist, kannst du auch etwas klarer indem werden, was du eigentlich meinst. Sonst reden wir hier ja im Kreis die ganze Zeit...


Keine Ahnung wie das heißt, ich nutz Eclipse nicht. In IntelliJ, XCode, Netbeans etc ist's ein Klick auf "Run" an Package, Klasse oder Methode, ganz ohne Plugin und alles...




Hyperbeast hat gesagt.:


> Wenn du wirklich dran Interesse hast zu wissen was der Sinn dahinter ist, kläre ich dich gerne darüber auf.


Ja, hab ich.


----------



## Hyperbeast (21. Okt 2016)

Also stark abgekürzt ist der Grund folgender... Wir haben verschieden Testsysteme auf denen eine Anwendung z.B. in der Version 1.0 läuft.

 Wenn wir jetzt eine Version 2.0 einspielen, kann der Tester dieses Tool nutzen und relativ einfach die standardisierten Tests durchjagen. Er benötigt dafür keine IDE, geschweige denn Java oder Entwickler-Kenntnisse.

Außerdem soll im Anschluss auf der GUI noch ein Feature hinzukommen um Testnachrichten an das Testsystem zu jagen. Die Testnachricht wählt man über ein Filesystem aus... Das wäre aber erst der nächste Schritt.

Macht das alles jetzt mehr Sinn?


----------



## Meniskusschaden (21. Okt 2016)

Hyperbeast hat gesagt.:


> Macht das alles jetzt mehr Sinn?


Ich habe den Sinn auch noch nicht erfasst. Normalerweise werden solche Tests doch vor Auslieferung von den Entwicklern durchgeführt. Hast du mal ein Beispiel, welche Art von Fehlern eure Kunden damit finden könnten, die ihr nicht selbst finden könnt. Das können ja eigentlich nur Dinge sein, die mit der konkreten Konfiguration oder dem Datenbestand des Kunden zu tun haben.


----------



## Hyperbeast (21. Okt 2016)

Mit "Kunde" meine ich unseren internen Tester. Und ja, die haben einen anderen Datenbestand.

PS: Ich würde mich freuen, wenn wir auf die eigentliche Frage zurückkommen könnten :-D


----------



## mrBrown (21. Okt 2016)

Hyperbeast hat gesagt.:


> PS: Ich würde mich freuen, wenn wir auf die eigentliche Frage zurückkommen könnten :-D


http://stackoverflow.com/questions/17551566/invoke-a-specific-junit-test-programmatically


----------



## Hyperbeast (21. Okt 2016)

mrBrown hat gesagt.:


> http://stackoverflow.com/questions/17551566/invoke-a-specific-junit-test-programmatically


Danke dir, das funktioniert schon mal. 
Habe mal eben eine kleine GUI mit Swing gebaut mit einem Button der dann die Testsuite ausführt. Wie gesagt, das funktioniert auch. Jetzt muss ich nur noch rausfinden wie ich eine .jar erzeugen kann die der "Kunde" dann startet (damit die GUI erscheint)...


----------



## mrBrown (21. Okt 2016)

warum soll das testen denn einzeln für verschieden TestSuites per GUI angestoßen werden?


----------



## Hyperbeast (21. Okt 2016)

mrBrown hat gesagt.:


> warum soll das testen denn einzeln für verschieden TestSuites per GUI angestoßen werden?


Weil TestSuite_1 andere Voraussetzungen benötigt, als TestSuite_2. Diese Voraussetzungen müssen manuell vom Tester erfüllt werden.


----------



## Jardcore (21. Okt 2016)

Also eigentlich ist es so, das in der ausgelieferten Software keine Testklassen mehr vorhanden sind.
Du kannst dir Builds erstellen, die deine Tests regelmäßig durchgehen und anzeigen ob irgendwelche Änderungen die Tests auf rot bringen.
Aus den erfolgreichen Builds kannst du dann die Software deployn. 

Wieso ein Kunde die Implementierung testen soll ist mir ein Rätsel.


----------



## SeriousD0nkey (21. Okt 2016)

Mit nem Jenkins oder einem TeamCity kann man doch auch Tests automatisch, oder eben manuell ausführen. Wäre das nicht eine Möglichkeit? Wobei ich das mit den verschiedenen Voraussetzungen nicht ganz verstehe..?


----------



## Hyperbeast (21. Okt 2016)

Jardcore hat gesagt.:


> Wieso ein Kunde die Implementierung testen soll ist mir ein Rätsel.


Wie mehrmals erwähnt ist unser Kunde der interne "Tester".



SeriousD0nkey hat gesagt.:


> Mit nem Jenkins oder einem TeamCity kann man doch auch Tests automatisch, oder eben manuell ausführen


Wir benutzen auch Jenkins aber der "Kunde" hat keinen Zugriff auf unsere Jenkinssysteme... Stellt euch vor, der Kunde hat NULL Ahnung von IT und er kennt auch kein Java, keine IDE und kein Jenkins etc. Er will aber "mal eben" Tests anstoßen. Oder eine beliebige Datei ans Testsystem senden. DAFÜR baue ich diese kleine Anwendung.

Aber wie gesagt, dass spielt alles überhaupt keine Rolle und bringt mich nicht ans Ziel.

Ich bin grad dabei herauszufinden wie ich nun meine Swing-Java Klassen ausführbar machen kann... Dann bin ich auch schon so gut wie fertig.


----------



## Hyperbeast (21. Okt 2016)

Alles klar, habe das nun auch rausgefunden. Meine Fragen wären dann soweit erstmal geklärt.


----------



## Jardcore (21. Okt 2016)

Kannst du deine Ergebnisse teilen, damit der nächste schneller auf eine Lösung stößt?
Ganz nach dem Motto: Wissen ist eines der Dinge die man teilen kann und die dadurch mehr werden


----------



## Hyperbeast (21. Okt 2016)

Man muss einfache eine "Runnable Jar" erstellen... dies geht über File -> Export ; Java -> Runnable JAR file

Jetzt heißt es erstmal Feierabend vielleicht melde ich mich nochmal nächste Woche falls ich gegen eine Wand laufe.  

Danke für eure Hilfe!


----------



## mrBrown (21. Okt 2016)

Hyperbeast hat gesagt.:


> Man muss einfache eine "Runnable Jar" erstellen... dies geht über File -> Export ; Java -> Runnable JAR file


Irgendwie hätte ich jetzt ... mehr erwartet


Rein aus Interesse, damit soll nachher die fertige Anwendung getestet werden und nicht zum Ausführen von Unit-Tests dienen?


----------



## dzim (24. Okt 2016)

Also erst einmal eine Richtigstellung: Eclipse hat per Default die entsprechende JUnit-Plugins installiert (und das schon, solange ich Eclipse kenne, also seit den frühesten 3.x-Versionen Anfang/Mitte der 00er). diese geben dir Graphisch genau das wieder, was deine Skizze aus dem initialen Post beschreibt. Aber sei's drum. 
Was ich lustig finde: Wenn der Tester keine Ahnung von IDE und Java (in dem Beipiel hier) hat, wie soll er selbst Tests definieren können, die er ausführen möchte? Sag jetzt bitte nicht, dass die Entwickler diese implementieren müssen, denn dann schmeiß' ich mich auf dem Boden und lache.


----------



## Hyperbeast (24. Okt 2016)

Genau.


dzim hat gesagt.:


> Sag jetzt bitte nicht, dass die Entwickler diese implementieren müssen, denn dann schmeiß' ich mich auf dem Boden und lache


Ich hoffe du hast einen sauberen Boden!

Aber so ist es halt in der Berufswelt...


----------



## Hyperbeast (24. Okt 2016)

mrBrown hat gesagt.:


> Rein aus Interesse, damit soll nachher die fertige Anwendung getestet werden und nicht zum Ausführen von Unit-Tests dienen?



Da verstehe ich nicht genau was du meinst... die fertige Anwendung wird durch die Unit-Tests getestet, welche von der "kleinen GUI" angestoßen werden.


----------



## dzim (24. Okt 2016)

Hab es gerade gecheckt. Werde den Putzleuten ein paar Stellen empfehlen, genauer anzusehen....

L.O.L.

Warum ich mich so amüsiere, ist dir hoffentlich klar, oder? Wenn die Entwickler die Tests schreiben und der "Tester" sie nur antösst, dann ist der Sinn seiner Stelle komplett verfehlt. Denn der Entwickler **könnte** - ich will niemanden was unterstellen - dafür sorgen, dass er immer erfolgreich ist. Ist nun doch ein Fehler da bekommt wer eins auf die Kappe? der Tester, nicht der Entwickler. Also der Sinn wurde um Meilen verfehlt.


----------



## Hyperbeast (24. Okt 2016)

Ich versteh dich schon  aber nach ein paar Jährchen im Beruf regt man sich über so etwas gar nicht mehr auf. Verschwendete Energie.


----------



## dzim (24. Okt 2016)




----------



## SeriousD0nkey (24. Okt 2016)

Also zum Thema Berufswelt: Wir, die Entwickler, schreiben selber Tests und gucken ob sie erfolgreich durchlaufen. Zusätzlich führt unser TeamCity die Tests nochmal extra durch, sobald wir etwas einchecken. Einen Tester haben wir auch, aber der guckt sich einerseits das wirkliche Produkt an (in dem Fall das Frontend) oder Testet das Java-Backend (bspw. mit Testsuits über SoapUI).


----------



## mrBrown (24. Okt 2016)

SeriousD0nkey hat gesagt.:


> Also zum Thema Berufswelt: Wir, die Entwickler, schreiben selber Tests und gucken ob sie erfolgreich durchlaufen. Zusätzlich führt unser TeamCity die Tests nochmal extra durch, sobald wir etwas einchecken. Einen Tester haben wir auch, aber der guckt sich einerseits das wirkliche Produkt an (in dem Fall das Frontend) oder Testet das Java-Backend (bspw. mit Testsuits über SoapUI).


Kenn ich auch so - UnitTests die Entwickler, System-/Integration-/Whatever-Test jemand anders


----------



## dzim (25. Okt 2016)

Eben, aber wenn der Tester nur die vom Entwickler geschriebenen Unit-Tests noch einmal ausführt. Das finde ich etwas befremdlich. Ich kenn' die QA eben als die, die sozusagen Out-of-the-Box agieren und handeln und die auf die Test-Installationen der Anwendung(en) losgelassen werden.


----------

