Wie JUnit auf 4.6 in eclipse updaten?

[0x7F800000]

Hallo Leute!

Ich bin's wieder mal, mit einer total dämlichen Frage, bei der ich allerdings nicht weiterkomme

Wie update ich in Eclipse dieses JUnit auf eine neuere Version?
Habe mir neulich die neueste Version von Ganymede runtergeladen, aber da wird anscheinend junit4_4.3.1 verwendet, auf der junit-seite steht aber, dass sie bereits 4.6 fertig rausgebracht haben. Zudem will ich ganz dringend org.junit.Assume benutzen können (gibt's bei meiner Version gar nicht :bahnhof.

Mit diesem Update-system von eclipse komme ich aber irgendwie nicht klar.
Bei diesem fensterchen unter Help->SoftwareUpdates habe ich irgendwie überhaupt nichts entdeckt, was den "Wortstamm" JUnit enthalten würde :rtfm:
Auf der Seite von JUnit sehe ich auch nur neue päckchen, die man in gezippter form runterladen kann, aber irgendwie keine eclipse-software-update seite, die man sonst bei neuen plugins in eclipse hinzufügen kann.

google spuckt nur tonnenweise crashkurse zu JUnit aus, immer derselbe shice in grün blau und lila :wuerg:

Forumsuche hat auch nicht viel ergeben, aber bei einer analogen Frage zu netbeans hat L-ectron-X kurz empfohlen, das software-update System von netbeans zu benutzen, deswegen denke ich mal, dass es bei eclipse nicht viel anders sein wird.

Ich könnte natürlich versuchen, das neue junit-päckchen als ganz normales externes jar einzubinden, aber ich glaube nicht, dass eclipse damit was anfangen kann (woher soll zB dieser alte JUnit-runner wissen, wie er mit gescheiterten Assume-methoden umzugehen hat?)

Könnte mir jemand mal einen Tipp geben? :rtfm:
Vielen dank im Voraus!

greetz, Andrey.

 

[mvitz]

Afaik ist JUnit mit im Java Development Plugin von Eclipse (ka wie das genau heißt).

Was du zum updaten machen könntest wäre evtl einfach die jar von eclipse mit der aktuellen ersetzen, weiß allerdings nicht ob das so das ideale mittel ist.

 

[maki]

Ich hab bis jetzt immer JUnit als externe lib eingebunden.

 

[0x7F800000]

Afaik ist JUnit mit im Java Development Plugin von Eclipse (ka wie das genau heißt).

Was du zum updaten machen könntest wäre evtl einfach die jar von eclipse mit der aktuellen ersetzen, weiß allerdings nicht ob das so das ideale mittel ist.

ja, imho kann's nicht so einfach sein, weil ja auch dieser plugin, der alles graphisch darstellt (d.h. dieses rot-grüne rechteck hinmalt^^) auch an die neuen anforderungen angepasst werden müsste, nur wie?

Ich hab bis jetzt immer JUnit als externe lib eingebunden.

Okay, habe ich eben versucht, es klappt, es wird auch als JUnit-test ausgeführt, aber wieso zum henker wird denn dieser test grün?

import org.junit.*;
import static org.junit.Assert.*;
import static org.junit.Assume.*;

public class TestTest {
	@Test
	public void test(){
		assumeTrue(4==5);
		assertEquals(4,2+2);
	}
}

irgendwas müsste er mir doch sagen, weil meine annahmen ja nicht stimmen
Aber die alte "JUnit-Umgebung" scheint diese assumtions einfach zu ignorieren :autsch:
Wie krieg ich das denn hin? Brauche noch einen tipp... ???:L

Danke schonmal!

 

[fjord]

Hab mich damit noch nicht wirklich auseinander gesetzt, aber in der API steht doch

public static void assumeTrue(boolean b)

    If called with an expression evaluating to false, the test will halt and be ignored.

    Parameters:
        b -

Dein Ausdruck ist falsch und deswegen wird der Test ignoriert würde ich sagen.

 

[SvenK]

Dein Ausdruck ist falsch und deswegen wird der Test ignoriert würde ich sagen.

Genau so ist es. Folgender Test fällt durch, da der Ausdruck in assumeTrue wahr und das assertEquals unwahr ist

public class TestKlasse {

	@Test
	public void test() {
		assumeTrue(4 == 4);
		assertEquals(4, 2 + 1);
	}
}

Assume ist kein Ersatz/Äquivalent für Asserts, sondern sie besagen einfach nur aus, dass Tests bei bestimmten Bedingungen ignoriert werden sollen

 

[0x7F800000]

Assume ist kein Ersatz/Äquivalent für Asserts, sondern sie besagen einfach nur aus, dass Tests bei bestimmten Bedingungen ignoriert werden sollen

Ja, genau wegen der tollen Eigenschaft habe ich eigentlich die ganze Sache mit 4.6 angefangen. Denn momentan habe ich in manchen tests 10 asserts die voraussetzungen prüfen, und einen, der wirklich etwas neues testet.
Die meisten asserts will ich durch assume ersetzen, weil sie ja nicht auf das versagen des getesteten codes hinweisen, sondern darauf, dass der Test falsch geschrieben wurde.
Bei falschen assumptions sollten die Tests ignoriert werden.

Was macht dieser Runner bei eclipse aber?

import org.junit.*;
import static org.junit.Assert.*;
import static org.junit.Assume.*;

public class TestTest {
	@Test
	public void test1(){
		assumeTrue(4==5); 
		assertEquals(4,2+2); 
	}
	
	@Test
	public void test2(){
		assumeTrue(4==5);
		assertEquals(4,2+3);
	}
	
	@Test
	public void test3(){
		assumeTrue(4==4);
		assertEquals(4,2+2);
	}
	
	@Test
	public void test4(){
		assumeTrue(4==4);
		assertEquals(4,2+3);
	}
	
	@Ignore
	@Test
	public void test5(){
		fail("warum auch immer");
	}
}

Das sind mir zwei ignorierte Tests zu wenig.

Wie ich diesen runner in eclipse update ist für mich bisher aber rätselhaft :bahnhof:

 

[SvenK]

Jetzt versteh ich, was du meinst. Das Ignore in dem JUnit-View kommt ja von der Annotation @Ignore und nicht von den Assumes.

Nun ist aber die Frage, womit willst du den Runner updaten? Es gibt keine neuere Version, die diese Assumes ebenfalls als Ignores anzeigt. ???:L

Denn entscheident ist ja der Eclipse-View, nicht die verwendete JUnit-Version. Wenn der View diese Information nicht auslesen kann/will, ist es egal ob du bereits die 4.6er-Version verwendest.

Aber da es Assumes schon eine längere Zeit gibt (keine Ahnung ab welcher Version), gibt es vielleicht einen Grund wieso die ignorierten Tests (mittels assume) nicht angezeigt werden. Könnte man höchstens die JDT-Entwickler fragen

 

[0x7F800000]

Jetzt versteh ich, was du meinst. Das Ignore in dem JUnit-View kommt ja von der Annotation @Ignore und nicht von den Assumes.

ja, warum hätte ich da sonst @Ignore davorgeschrieben... :bahnhof:

Nun ist aber die Frage, womit willst du den Runner updaten? Es gibt keine neuere Version, die diese Assumes ebenfalls als Ignores anzeigt. ???:L

Ich hab keine Ahnung. Ich hab dieses junit nicht gebaut, und von eclipse plugins habe ich genauso 0 plan... Was diese ganzen Runner aus org.junit.runners eigentlich machen verstehe ich auch nicht, anscheinend hat es keinen einfluss auf das ergebnis, was ich da in @RunWith davorschreibe. Von den FAQ's von JUnit wurde ich auf irgeneine veraltete Hilfeseite weitergeleitet, wo sich alles auf 3.x bezog, und habe da auch in der Konsole nichts außer ClassCastExceptions hinbekommen (die bei 4.x-Tests natürlich kommen mussten).

Denn entscheident ist ja der Eclipse-View, nicht die verwendete JUnit-Version. Wenn der View diese Information nicht auslesen kann/will, ist es egal ob du bereits die 4.6er-Version verwendest.

dass nix läuft sehe ich ja, könnte mir jetzt vielleicht einer erzählen was ich tun soll damit es läuft?
...Also mittlerweile blicke ich überhaupt nicht mehr durch, wie ich mit junit 4.6 überhaupt irgendwas anstelle, wozu ist der ganze code da, wie war es gedacht, womit starte ich den krempel überhaupt? :autsch:

Wenn ihr mir sagt, dass es irgendein anderes (brauchbares!) plugin zum testen gibt, testNG oder was auch immer, dann akzeptiere ich das auch, ich will halt einfach irgenwie tests zum laufen bringen, irgendwie muss das doch gehen ???:L

 

[maki]

Was ist denn das Problem?

Solltest dich imho nicht an Assume aufhängen, ist sowieso nicht wichtig.

Ehrlich gesagt verstehe ich nicht ganz wozu du Assume nutzen (missbrauchen?) willst.

 

[SvenK]

Ich versteh dein Problem auch nicht. Ich und viele tausend andere setzen JUnit unter Eclipse ein und es funktioniert doch, ob nun mit 4.4, 4.5 oder 4.6 ...

Was meinst du denn mit "was soll ich tun, damit es läuft"? ???:L Es läuft doch

Edit:
Wenn du damit meinst, wie du JUnit 4.6 zum laufen bekommst: eben nicht mit dem integrierten Plugin (das ist eben in der Version 4.3). Das 4.6 musst du eben als externe Jar einbinden. Voilá

 

[0x7F800000]

Ehrlich gesagt verstehe ich nicht ganz wozu du Assume nutzen (missbrauchen?) willst.

Zum beispiel um zu kontrollieren, dass ich komplexere erwartete ergebnisse korrekt eingetippt habe.

Beispielsweise wenn ich sowas eintippen muss:
http://upload.wikimedia.org/wikipedia/commons/d/d2/Minimum_spanning_tree.svg
dann will ich zumindest zwischendurch kurz überprüfen, ob das, was ich da eingetippt habe, wirklich 10 Knoten und 21 Kanten hat.

Assert ist da nicht angebracht: mein Tippfehler im testcode macht den eigentlichen code nicht falscher...

Und dennoch bin im moment durch diesen dämlichen nicht updatebaren eclipse-plugin dazu mehr oder weniger gezwungen, stattdessen asserts zu verwenden:

	@Test
	public void testGetMinimalUndirectedSpanningForest(){
		//example from wikipedia [url]http://upload.wikimedia.org/wikipedia/commons/d/d2/Minimum_spanning_tree.svg[/url]
		//nodes are labeled with letters from left to right
		DirectedMultigraph<String,Integer> g=new DirectedMultigraph<String,Integer>();
		g.addEdge("a","b",3);
		g.addEdge("a","d",6);
		g.addEdge("a","e",9);
		g.addEdge("b","c",2);
		g.addEdge("b","d",4);
		g.addEdge("b","e",9);
		g.addEdge("b","f",9);
		g.addEdge("c","d",2);
		g.addEdge("c","g",9);
		g.addEdge("c","f",8);
		g.addEdge("d","g",9);
		g.addEdge("e","f",8);
		g.addEdge("e","j",18);
		g.addEdge("f","g",7);
		g.addEdge("f","i",9);
		g.addEdge("f","j",10);
		g.addEdge("g","h",4);
		g.addEdge("g","i",5);
		g.addEdge("h","i",1);
		g.addEdge("h","j",4);
		g.addEdge("i","j",3);
		
		assertEquals(10,g.getNumberOfVertices()); 
		assertEquals(21,g.getNumberOfEdges());
		
		DirectedMultigraph<String,Integer> mst=new DirectedMultigraph<String,Integer>();
		mst.addEdge("a","b",3);
		mst.addEdge("b","c",2);
		mst.addEdge("c","d",2);
		mst.addEdge("c","f",8);
		mst.addEdge("e","f",8);
		mst.addEdge("f","g",7);
		mst.addEdge("g","h",4);
		mst.addEdge("h","i",1);
		mst.addEdge("i","j",3);
		
		assertEquals(10,mst.getNumberOfVertices());
		assertEquals(9,mst.getNumberOfEdges());
		
		assertEquals(mst,g.getMinimalUndirectedSpanningForest(new WeightFunction<Integer>(){
			@Override
			public double getWeight(Integer x){
				return x;
			}
		}));
	}

das ist scheiße, weil ich da fünf asserts drin habe, von den nur einer den code testet, die anderen vier stellen dagegen die korrektheit des tests sicher. Das ist hässlich. Wenn das besser geht, würde ich das gerne machen.

 

[0x7F800000]

Ich versteh dein Problem auch nicht. Ich und viele tausend andere setzen JUnit unter Eclipse ein und es funktioniert doch, ob nun mit 4.4, 4.5 oder 4.6 ...

daher wundert mich umso mehr, wieso ich nirgends was finde, wie ich diese Assumes in eclipse ordentlich verwende.

Was meinst du denn mit "was soll ich tun, damit es läuft"? ???:L Es läuft doch

Ja, was läuft... wenn man überall nur asserts hinpflanzt läuft's natürlich. Aber assumes werden nun mal nicht korrekt behandelt (siehe doch den Screenshot oben! ;( ), das was dieser junit runner von eclipse da mit assume macht ist wesentlich irreführender, als wenn ich alle assumes durch asserts ersetzen würde. :autsch:

Das 4.6 musst du eben als externe Jar einbinden. Voilá

Okay, sorry, ich bin eben dämlich, ich raff's immer noch nicht. Voila was? Ich habe ja jetzt 4.6 als externes jar eingebunden, super, ich darf da jetzt Assume verwenden, aber was soll mir das bringen, wenn die tests nicht korrekt ausgeführt werden, und der runner einfach jeden fehlerhaften dreck ohne jegliche Warnungen einfach so grün anmalt? ???:L

Kurz zusammengefasst lautet die frage nach wie vor:
Ich habe 4.6 als externes jar eingebunden, wie mache ich davon jetzt gebrauch?

 

[maki]

eil ich da fünf asserts drin habe, von den nur einer den code testet, die anderen vier stellen dagegen die korrektheit des tests sicher. Das ist hässlich. Wenn das besser geht, würde ich das gerne machen.

Ok, jetzt verstehe ich (dauert manchmal ein bisschen )

Testdaten zu erstellen ist mühsam und die meisten Fehler werden anfangs dort gemacht, ist also normal imho.

Eine Alternative wären Mockobjekte, ein zusätzlicher Bonus bei der Benutzung von Mocks ist, dass du wirklich nur das SUT (System/Subject under Test) testest und nicht alles drumherum und dadurch eben nicht mehr von der Korrektheit von "allem drumherum" abhängig bist und gleichzeitig abhängigkeiten reduzierst (meist nur noch auf die Schnittstelle).

Ich nutze JMock, da gibt es sog. Expectations, da kannst du einerseits festlegen welche/ob Methoden aufgerufen werden, und welche Werte zurückgeliefert werden.
Du brauchst also keine "echten" komplexen Objekte zu konstruieren um dein SUT zu testen, sondern sagst deinem Mock wie er sich zu verhalten hat.

 

[SvenK]

Noch mal zum Mitschreiben: Assumes gibt es schon ewig in JUnit, wahrscheinlich schon seit 1.x

Das Problem ist eben dieser View, der deine "getriggerten" Assumes nicht als ignorierte Tests anzeigt. Und da gibt es keine neue Version.


Wenn es um deine Testdaten geht, wäre es nicht verkehrt wenn du die über ein Mocking-Objekt lieferst. Das ist aber ein Thema für sich. Ich sag nur EasyMock

 

[0x7F800000]

Testdaten zu erstellen ist mühsam und die meisten Fehler werden anfangs dort gemacht, ist also normal imho.

ist mir schon aufgefallen... Unter anderem aus diesem grund würde ich die tests eigentlich recht gerne möglichst sauber hinschreiben, für den fall dass ich sie nochmal brauche... Dazu gehört imho auch, dass ich die logisch völlig verschiedene Sachen wie assert und assume im code auseinanderhalte, das steigert ja auch die lesbarkeit.

Eine Alternative wären Mockobjekte, ein zusätzlicher Bonus bei der Benuztung von Mocks ist, dass du wirklich nur das SUT (System/Subject under Test) testest und nicht alles drumherum und dadurch eben nicht mehr von der Korrektheit von "allem drumherum" abhängig bist und gleichzeitig abhängigkeiten reduzierst (meist nur noch auf die Schnittstelle).

Ich nutze JMock, da gibt es sog. Expectations, da kannst du einerseits festlegen welche/ob Methoden aufgerufen werden, und welche Werte zurückgeliefert werden.
Du brauchst also keine "echten" komplexen Objekte zu konstruieren um dein SUT zu testen, sondern sagst deinem Mock wie er sich zu verhalten hat.

verstehe leider nicht wie mich das hier weiterbringen soll, bei dieser methode wird nur eine einzige spezielle union-find datenstruktur benutzt, die ich bereits separat getestet habe, und die eigentlich beinahe "too simple to break" ist. Ich will doch einfach nur schauen, ob das was die methode liefert dasselbe ist, wie das was ich erwarte. Da gibt es keine abhängigkeiten, und an dieser Graphenklasse ist nichts komplexes verlinkt, was man mocken müsste...

Das Problem ist eben dieser View, der deine "getriggerten" Assumes nicht als ignorierte Tests anzeigt.

zum x-ten mal "ja", das hast du völlig korrekt verstanden.

Und da gibt es keine neue Version.

bist du dir sicher oder glaubst du das nur? Bei deinem letzten Beitrag mit derselben aussage endete der Satz mit dem verunsicherten "???:L"-smiley...

Wenn das so ist, dann reduzieren sich die möglichkeiten auf:
a) JUnit+Eclipse funzt nicht so richtig, damit muss man leben und assume vergessen, stattdessen überall assert verwenden. Egal, wenn's nicht einfach auszubessern ist, soll es doch so bleiben.

b) Irgendein anderes testing-Framework verwenden. Kann da wer was empfehlen?
JMock und EasyMock schaue ich mir bei Gelegenheit mal an, wobei mir momentan unklar ist, wie es bei diesem konkreten Problem helfen soll.

Okay, danke an alle.
Ich glaub ich bleibe einfach bei 123456789 asserts, halb so wild... :noe:

 

[maki]

Denke dein Problem ist nicht JUnit, sondern die Tatsache dass die Tests manuell aus Eclipse gestartet werden.

Ein guter Build testet sich selbst, für Maven gibt es das Surefire Plugin, dieses erstellt testsSuits automatisch und lässt sie alle durchlaufen, bei jedem Build.

Persönlich nutze ich keine Assumes, wusste ehrlich gesagt bis zu deinem Thread hier nicht das es welche gibt, verstehe aber den möglichen nutzen darin.
Leider scheint das Maven2 Surefire plugin sich auch fehlerhaft zu verhalten: [#SUREFIRE-542] JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped" - jira.codehaus.org
damit scheiden assumes für mich wieder aus...

 

[0x7F800000]

damit scheiden assumes für mich wieder aus...

okay, dann ist zu dem thema wohl nichts mehr zu sagen.
Ich glaube bei asserts, die statt assume eingesetzt werden, schreibe ich jedes mal als kommentar "wrong assumtion" hin oder so... :bahnhof:

Nochmal danke an alle.