JUnit: Testproblem.

Status
Nicht offen für weitere Antworten.

7crystal7

Mitglied
Hallo Leute,

ich lerne gerade nach http://www.frankwestphal.de/UnitTestingmitJUnit.html Unit Testing. Hierzu habe ich folgende Klasse Euro:

Code:
public class Euro {
	
  private long cents;
  
  public Euro(double euro) {
	 if (euro < 0.0) {
	    throw new IllegalArgumentException("Negative amount");
	 }
	 cents = Math.round(euro * 100.0);
  }
  
  public double getAmount() {
    return (cents / 100);
  }
  
  public int hashCode() {
	return (int) cents;
  }
  
  public Euro add(Euro other) {
	return new Euro(this.cents + other.cents);
  }
  
  public boolean equals(Object o) {
    if (o == null || !o.getClass().equals(this.getClass())) {
    	return false;
	}
	Euro other = (Euro) o;
	return this.cents == other.cents;
  }

}

und meine Testklasse:

Code:
import junit.framework.*;

public class EuroTest extends TestCase {

	  private Euro two;
	  
	  public EuroTest(String name) {
	    super(name);
	  }

	  protected void setUp() {
		two = new Euro(2.00);
	  }

	  protected void tearDown() {
		//two = null;
	  }
	  
	  public void testAmount() {
		assertTrue(2.00 == two.getAmount());
	  }

	  public void testRounding() {
		Euro roundedTwo = new Euro(1.995);
		assertEquals("rounded amount", 2.00, roundedTwo.getAmount(), 0.001);
	  }

	  public void testAdding() {
		Euro three = two.add(new Euro(1.00));
		assertEquals("two", 2.00, two.getAmount(), 0.001);
		assertEquals("sum", 3.00, three.getAmount(), 0.001);
	  }
	  
	  public void testEquality() {
		 assertEquals(two, two);
		 assertEquals(two, new Euro(2.00));
		 assertEquals(new Euro(2.00), two);

		 assertTrue(!two.equals(new Euro(0)));
		 assertTrue(!two.equals(null));
		 assertTrue(!two.equals(new Object()));
	  }
	  
	  public void testHashCode() {
		assertTrue(two.hashCode() == two.hashCode());
		assertTrue(two.hashCode() == new Euro(2.00).hashCode());
	  }
	  
	  public void testNegativeAmount() {
	    try {
	      final double NEGATIVE_AMOUNT = -2.00;
	      new Euro(NEGATIVE_AMOUNT);
	      fail("Should have raised an IllegalArgumentException");
		} 
		catch (IllegalArgumentException expected) {
			System.out.println("Exception works!");
		}
	  }
  
  public static void main(String[] args) {
    junit.swingui.TestRunner.run(EuroTest.class);
  }
}


Wieso funktioniert der testAdding nicht? Der Fehler lautet immer:
junit.framework.AssertionFailedError: sum expected:<3.0> but was:<300.0>


Könnt ihr mir weiterhelfen? Wäre dringend weil ich das wirklich nicht verstehe...

Vielen Dank,
Babsi
 

quippy

Bekanntes Mitglied
Your code works as designed! Und Junits funktionieren doch ;)

Schau mal in Deinen Konstruktor der Klasse €uro und dann dort in die Add-Methode. Wenn Du die Cents addierst (zwei Long-Werte) und keinen Konstruktor für long als Extrabehandlung hast, dann werden die Cents (200+100) nochmal mit hundert multipliziert und bei getAmount wieder durch 100 geteilt.

Deine add-Methode müßte lauten
Code:
return new Euro((this.cents + other.cents)/100.0); // Auf Float/Double achten, sonst wird das hier ganzzahlig

Wenn Du übrigens mal einen Debugger verwendet hättest, dann wäre Dir das auch so mal aufgefallen!
 
G

Guest

Gast
danke für die Antworten.. wie müsste ich denn die Klasse Euro modifizieren das der Test so wie er ist funktioniert?

Vielen Dank,
Babsi

P.S.: Wo stellt man das Logging und Debugging in Eclipse ein? Sorry -> Noob :-/
 
M

maki

Gast
Logging ist das Debugging für Arme bae.gif Also ne, da schaue ich lieber mal während der Laufzeit in den Code, als ihn mit Ausgaben zu spicken...
Umgekehrt wird ein Schuh draus ;)

Logging ist Fehlersuche für Fortgeschrittene, Debugging ist für verzweifelte bzw. wenn man zwar weiss wo der Fehler ist, aber noch nicht warum es falsch läuft.

Mit einem guten Logging Konzept spart man sich in 90% den Debugger und die Zeit.
 

7crystal7

Mitglied
ok, Debugging auch gefunden.. Kann man in Java nur nach unten steppen, nicht mehr zurück (also eine Zeile darüber z.B.)? Kenne das vom VB bidirektional..

Vielen Dank,
Babsi
 

quippy

Bekanntes Mitglied
maki hat gesagt.:
Logging ist das Debugging für Arme bae.gif Also ne, da schaue ich lieber mal während der Laufzeit in den Code, als ihn mit Ausgaben zu spicken...
Umgekehrt wird ein Schuh draus ;)

Logging ist Fehlersuche für Fortgeschrittene, Debugging ist für verzweifelte bzw. wenn man zwar weiss wo der Fehler ist, aber noch nicht warum es falsch läuft.

Mit einem guten Logging Konzept spart man sich in 90% den Debugger und die Zeit.

Das sehe ich anders.

Klar, wenn ich Logging betreibe, muß ich als Entwickler selbst entscheiden, wo die Knackpunkte im Programm sind, an denen ich irgendwelche Ausgaben sehen will - und zudem hinterher noch in der Lage sein, diese Ausgaben so zu interpretieren, daß reine Codeinspektion ausreicht, um den Fehler zu finden.

Aber wenn ich dann sowas sehe:

Code:
private void myMethod(int a, float b)
{
   System.out.println("Bin in myMethod");
   int x = irgendwas();
   System.out.println("X ist nun " + x);
   x += a;
   System.out.println("X ist nun " + x);
   x*=b;
   System.out.println("X ist nun " + x);
}

Dann bezweifle ich durchaus, ob Logging so eingesetzt wirklich gut ist. Da kann man auch sehr gut einmal mit dem Debugger durch, wenn's sein muss.
 

quippy

Bekanntes Mitglied
Anonymous hat gesagt.:
danke für die Antworten.. wie müsste ich denn die Klasse Euro modifizieren das der Test so wie er ist funktioniert?

Vielen Dank,
Babsi

P.S.: Wo stellt man das Logging und Debugging in Eclipse ein? Sorry -> Noob :-/

Lesen, Liebes, lesen!

quippy hat gesagt.:
Schau mal in Deinen Konstruktor der Klasse €uro und dann dort in die Add-Methode. Wenn Du die Cents addierst (zwei Long-Werte) und keinen Konstruktor für long als Extrabehandlung hast, dann werden die Cents (200+100) nochmal mit hundert multipliziert und bei getAmount wieder durch 100 geteilt.

Deine add-Methode müßte lauten
Code:
return new Euro((this.cents + other.cents)/100.0); // Auf Float/Double achten, sonst wird das hier ganzzahlig

Oder hilft das nicht?
 

byte

Top Contributor
maki hat gesagt.:
Logging ist das Debugging für Arme bae.gif Also ne, da schaue ich lieber mal während der Laufzeit in den Code, als ihn mit Ausgaben zu spicken...
Umgekehrt wird ein Schuh draus ;)

Logging ist Fehlersuche für Fortgeschrittene, Debugging ist für verzweifelte bzw. wenn man zwar weiss wo der Fehler ist, aber noch nicht warum es falsch läuft.

Mit einem guten Logging Konzept spart man sich in 90% den Debugger und die Zeit.
Sry aber das ist BS. :roll: Wie willst du per Logging den aktuellen Zustand der Objekte zur Laufzeit inspizieren? Du kannst wohl schlecht alle Werte mitloggen, ohne die Performance in den Keller zu treiben.
 
M

maki

Gast
Sry aber das ist BS. icon_rolleyes.gif Wie willst du per Logging den aktuellen Zustand der Objekte zur Laufzeit inspizieren? Du kannst wohl schlecht alle Werte mitloggen, ohne die Performance in den Keller zu treiben.
@byto
Kein BS, sondern Praxis.

Die Testmaschine loggt prinzipiell mit Debug Level für die interessanten Klassen, da sind die Tests um einiges aussagekräftiger und Fehler viel einfacher reproduzierbar.

Performance im Keller?
Sorry, aber das nehme ich nicht ernst.
Unsere Testmaschinen sind zwar schon 2 Jahre alt, aber ein Compaq/HP Sever mit 4 Xeon Prozesoren treibt das nicht in den Keller, dasselbe gilt für die Entwicklungsmaschinen, Duo Core.
Und auf meinem alten P4 war das auch nie ein Problem, den Debugger anzuschmeissen dauerte allerdings immer etwas ;)

Auf der Prod Maschine das Log level zur Laufzeit zu verändern (ohne neustart) ist auch nicht sonderlich schwer, falls gewünscht.

Abgesehen davon gibt es einfach Systeme die man nicht sinnvoll debuggen kann.

private void myMethod(int a, float b)
{
System.out.println("Bin in myMethod");
int x = irgendwas();
System.out.println("X ist nun " + x);
x += a;
System.out.println("X ist nun " + x);
x*=b;
System.out.println("X ist nun " + x);
}
@quippy
Das ist kein Logging! Höchstens Logging für ganz ganz arme...
Log4j ist mein Favourit.

Man muss auch nicht groß entscheiden was wichtig ist.
Schreib einfach am Anfang jeder public Methode (einfache getter und settern ausgenommen) den Namen der Methode und die übergebenen Parameter rein, das reicht für 80-90% aller Fälle und du musst gar nicht erst den debugger anwerfen, bei den anderen füge ich paar mehr logging Ausgaben hinzu.

Schon ma 'ne email von System bekommen wenn auf der Prod Maschine was zusammenbricht? Mit log4j gar kein Problem.
 

tfa

Top Contributor
maki hat gesagt.:
Sry aber das ist BS. icon_rolleyes.gif Wie willst du per Logging den aktuellen Zustand der Objekte zur Laufzeit inspizieren? Du kannst wohl schlecht alle Werte mitloggen, ohne die Performance in den Keller zu treiben.
@byto
Kein BS, sondern Praxis.

Klar ist Logging Praxis, ebenso wie Debugging - beides sehr wichtige Hilfsmittel bei der Softwareentwicklung.
Ich würde nicht sagen, das eine sei besser als das andere. Beides hat eben verschiedene Anwendungsbereiche.
Ich glaube byto wollte sagen, dass es unsinnig ist, jede Programmzeile mitzuloggen. Oder würdest Du (um mal auf Babsis Problem vom Anfang zurückzukommen) folgendes machen?
Code:
public Euro(double euro) { 
    LOG.debug("Neues Euro-Objekt anlegen mit euro="+euro);
    if (euro < 0.0) { 
       throw new IllegalArgumentException("Negative amount"); 
    } 
    cents = Math.round(euro * 100.0); 
    LOG.debug("Eurobetrag umgerechnet in Cents="+cents);
  }

Sicherlich nicht. Hätte man aber, um dieses Fehler zu finden.
Wie groß und unübersichtlich wären dann die Log-Dateien und wie lange bräuchte man, um was vernünftiges darin zu finden?

Ich meine, die richtige Antwort auf einen fehlgeschlagenen Unit-Test ist Debugging (und nur Debugging).
Man weiß ja sogar schon, wo man den Breakpunkt machen muss. Warum also Log-Datein durchsuchen?
 

byte

Top Contributor
Eben. Es ist einfach viel komfortabler, wenn ich einfach per Breakpoint in die Methode springe, wo etwas faul ist und ich auf einen Blick die Zustände alle relevanten Objekte sehen kann. Und eine App im Debugmodus zu starten, dauert kaum länger als normal. Im übrigen kannst Du Hot Code Replacement beim Debuggen benutzen, musst also gar nicht ständig die Anwendung neu starten, wenn Du Code änderst.
Mag aber sein, dass es mehrschichtige EE Anwendungen gibt, wo Debugging nicht so toll geht. Das kann ich nicht so beurteilen, weil ich bisher wenig mit App.servern gearbeitet habe.
 

quippy

Bekanntes Mitglied
Man muss auch nicht groß entscheiden was wichtig ist.
Schreib einfach am Anfang jeder public Methode (einfache getter und settern ausgenommen) den Namen der Methode und die übergebenen Parameter rein, das reicht für 80-90% aller Fälle und du musst gar nicht erst den debugger anwerfen, bei den anderen füge ich paar mehr logging Ausgaben hinzu.

Schon ma 'ne email von System bekommen wenn auf der Prod Maschine was zusammenbricht? Mit log4j gar kein Problem.

Wir nutzen hier auch Log4J und das ist schon super. Allerdings würde die Taktik von Dir die Logs der Server schon ziemlich vollpumpen. Klar, man kann je nach Kontext/Pakage einstellen, wie der Loglevel sein soll, aber performant ist das trotzdem nicht unbedingt!

Vor allem, wenn man das so macht:
Code:
private void function(int a, ComplextType[] array)
{
   if (Log.isDebug(CATEGORY))
       Log.debug(CATEGORY, "function:  " + a + ", " + Array.toString(array));
}

Diese ganzen Stringkonkatenierungen sind nur für's Debugging da und das macht alles wirklich langsam. Der vorherige Test mit "if Log.isDebug()" hilf da schon, trotzdem - das würde ich lassen.

Ich persönlich streue Loggings nur dort ein, wo ich bei einem Produktionsfehler schnell im Log sehen können will, was da wohl schief gelaufen sein könnte - wärend der Entwicklung benutze ich grundsätzlich Debugging. Vom Logging bleibt nur das im Coding, was wie gesagt in der Produktivumgebung benötigt wird - und das sollte einfach nicht zu viel sein! Wir haben da jedenfalls schon mal viel Energie reingesteckt, um Performanceeinbußen durch übertriebenes Logging (gerade wegen der Stringverarbeitung) auszubauen!
 

quippy

Bekanntes Mitglied
byto hat gesagt.:
Mag aber sein, dass es mehrschichtige EE Anwendungen gibt, wo Debugging nicht so toll geht. Das kann ich nicht so beurteilen, weil ich bisher wenig mit App.servern gearbeitet habe.

Du kannst (z.B. bei Eclipse) dich an einen JBoss im Debug-Modus dranklemmen und wie gewohnt debuggen. Bei verteilten Systemen mit EJBs etc. ist das allerdings nicht immer ganz trivial!
 
M

maki

Gast
@tfa
Klar ist Logging Praxis, ebenso wie Debugging - beides sehr wichtige Hilfsmittel bei der Softwareentwicklung.
Natürlich geht es nicht ohne Debugging, dass hab ich ja auch nicht behauptet, aber es gibt Situationen, in denen Debugging nicht möglich/sinnvoll ist.
Abgesehen von EJBs ist man in komplexeren Frameworks mit Debugging auch nicht gut beraten, die Komplexität erschlägt einen.

Ich glaube byto wollte sagen, dass es unsinnig ist, jede Programmzeile mitzuloggen.
Da stimme ich zu.

Oder würdest Du (um mal auf Babsis Problem vom Anfang zurückzukommen) folgendes machen?
Mag sein das man mich jetzt auslacht, aber manchmal mach ich das, weil ich muss/es besser ist.
Ein Logging statement schreib ich nur ein einziges mal, kann es immer auswerten.
Zugegeben, in diesem Beispiel wäre Debuggen möglich und besser weil effizienter und weniger aufwendig.

Ich meine, die richtige Antwort auf einen fehlgeschlagenen Unit-Test ist Debugging (und nur Debugging).
Das sehe ich anders, "unser" DAO Framework zB lässt sich kaum sinnvoll Debuggen, meine Unittests für die DAOs können nur selten sinnvoll debuggt werden.
Da kommt es aufs log an und was in der DB angekommen ist.
Steht ja genau da was wo passiert ist bevor die Exception geworfen wurde.

Man weiß ja sogar schon, wo man den Breakpunkt machen muss. Warum also Log-Datein durchsuchen?
Wenn ich weiss wo der Fehler war und welche Werte diesen Fehler verursacht haben, hab ich es meist nicht mehr nötig den Debugger anlaufen zu lassen.
Ich suche übrigens nach dem Methodennamen im Log um die Werte herauszufinden ;)
Wenn die Log Einstellungen richtig sind, hat man auch nicht zuviel "Schrott" über den man lesen muss.

@byto
Es ist einfach viel komfortabler, wenn ich einfach per Breakpoint in die Methode springe, wo etwas faul ist und ich auf einen Blick die Zustände alle relevanten Objekte sehen kann. Und eine App im Debugmodus zu starten, dauert kaum länger als normal. Im übrigen kannst Du Hot Code Replacement beim Debuggen benutzen, musst also gar nicht ständig die Anwendung neu starten, wenn Du Code änderst.
Tomcat im Debug Modus starten dauert ein bisschen, geht aber meist problemlos, allerdings funzt der Hot Code Replacement nicht, damit wäre nach jeder Änderung ein Neustart erfoderlich(ausser bei Änderungen in JSPs).
Das wars dann auch schon mit der Komfortablität...

Naja, was für mich funktioniert muss ja nicht für jeden funktionieren, kann dir aber sagen, das der Debugger bei mir eher die Ausnahme bei der Fehlersuche ist.
 
M

maki

Gast
Diese ganzen Stringkonkatenierungen sind nur für's Debugging da und das macht alles wirklich langsam. Der vorherige Test mit "if Log.isDebug()" hilf da schon, trotzdem - das würde ich lassen.
Wenn das if drinn ist, das ist es eine einzige Abfrage die gemacht wird, da geht nix an Performance verloren was du merken könntest.

Abgesehen davon sind diese String Verkettungen nicht wirklich so langsam, da intern StringBuilder/StringBuffer verwendet wird, einfach mal den Kompilierten Code dekompilieren.
Was Zeit kostet ist die Daten zu Loggen, nicht die Stringverkettung, wenn nicht geloggt wird (die if Abfrage), kostet es auch keine echte Performance.
 

quippy

Bekanntes Mitglied
maki hat gesagt.:
Diese ganzen Stringkonkatenierungen sind nur für's Debugging da und das macht alles wirklich langsam. Der vorherige Test mit "if Log.isDebug()" hilf da schon, trotzdem - das würde ich lassen.
Wenn das if drinn ist, das ist es eine einzige Abfrage die gemacht wird, da geht nix an Performance verloren was du merken könntest.

In meinem Post steht ja drin, daß durch die Abfrage das schon besser ist - aber wenn das Logging für diesesen Kontext auf Debug-Level steht, dann greift's auch.
Ich weiß nun nicht, was Java5 aus den Stringkonkatenierungen so macht, aber J4 und kleiner hat da doch sowas gemacht:
Code:
aus
   String a = "hallo" + " - " + " Welt";
wird
   StringBuffer t1 = new StringBuffer("hallo");
   t1.append(" - ");
   String t2 = t1.toString();
   StringBuffer t3 = new StringBuffer(t2);
   t3.append(" Welt");
   String a = t3.toString();
Oder war das auch schon besser? Viele Entwickler (mich eingeschlossen) formulieren zeitkritische Stringverarbeitungen ja lieber manuell mit StringBuffer - was ja durchaus historisch bedingt sein kann.

Übrigens frage ich mich nun wirklich, ob wir die Diskussion nicht beenden oder in einen anderen Thread verscheiben sollten. Wir sind alle eigentlich der gleichen Meinung - jeder verwendet Logging oder Debugging so, wie es für Ihn im konkreten Fall notwendig ist.
 

quippy

Bekanntes Mitglied
Code:
public class Euro {
	
  private long cents;
  
  public Euro(double euro) {
	 if (euro < 0.0) {
	    throw new IllegalArgumentException("Negative amount");
	 }
	 cents = Math.round(euro * 100.0); // <----- Du verwendest CENTS
  }
  
  public double getAmount() {
    return (cents / 100); // <---- und konvertierst hier!
  }
  
  public int hashCode() {
	return (int) cents;
  }
  
  public Euro add(Euro other) {
	//return new Euro(this.cents + other.cents); // <----- Hier ist der Fehler
	//return new Euro((this.cents + other.cents) / 100); // möglicher FIX
	return new Euro(this.getAmount() + other.getAmount()); // der bessere FIX
  }

  public boolean equals(Object o) {
    if (o == null || !o.getClass().equals(this.getClass())) {
    	return false;
	}
	Euro other = (Euro) o;
	return this.cents == other.cents; // <--- Das ist OK
  }

}

Hier nochmal der FIX für Babsi, weil ich nicht weiß, ob Sie's nun gelesen hat!
 
M

maki

Gast
Oder war das auch schon besser? Viele Entwickler (mich eingeschlossen) formulieren zeitkritische Stringverarbeitungen ja lieber manuell mit StringBuffer - was ja durchaus historisch bedingt sein kann.
Eher historisch und heute gar nicht mehr so gut:
http://java.sun.com/developer/technicalArticles/Interviews/community/kabutz_qa.html

Übrigens frage ich mich nun wirklich, ob wir die Diskussion nicht beenden oder in einen anderen Thread verscheiben sollten. Wir sind alle eigentlich der gleichen Meinung - jeder verwendet Logging oder Debugging so, wie es für Ihn im konkreten Fall notwendig ist.
Auch wieder richtig! :)
 

tfa

Top Contributor
quippy hat gesagt.:
Ich weiß nun nicht, was Java5 aus den Stringkonkatenierungen so macht, aber J4 und kleiner hat da doch sowas gemacht:
Code:
aus
   String a = "hallo" + " - " + " Welt";
wird
   StringBuffer t1 = new StringBuffer("hallo");
   t1.append(" - ");
   String t2 = t1.toString();
   StringBuffer t3 = new StringBuffer(t2);
   t3.append(" Welt");
   String a = t3.toString();

Das glaub ich nicht. Die Konkatenation von Stringliteralen wurde schon immer (mindestens seit 1.3) korrekt aufgelöst (also in String a="hallo - Welt") -- jedenfalls von Suns javac (bei z.B. jikes sah das damals anders aus).
Dass für jeden String ein neuer Buffer angelegt wurde, wage ich auch zu bezweifeln.

Abgesehen von der Performance würde mich das Zumüllen des Quelltextes durch exzessives Logging glaub ich auch stören. Eine Zeile ist ok, aber dann noch ein if davor...
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
Zrebna Wieso sind eigentlich JUnit-Tests in src/test/java platziert - nur Konvention? Allgemeine Java-Themen 7
harrytut Java Input/Output Tests Junit Allgemeine Java-Themen 3
B Junit Test Allgemeine Java-Themen 8
J Junit surefire: enrich test information Allgemeine Java-Themen 0
J Junit start surefire for manual testing Allgemeine Java-Themen 1
P No JUnit tests found Allgemeine Java-Themen 5
F Junit Test + Cucumber - JSON auslesen und in einem weiteren Schritt nutzen Allgemeine Java-Themen 0
J JUnit - Auslassen von Code Allgemeine Java-Themen 25
S Zugriff auf jUnit Test Suite Runner-Instanzen innerhalb von Test Classes Allgemeine Java-Themen 7
S Eclipse Probleme beim Implementieren / Ausführen von jUnit 5-Test Suites Allgemeine Java-Themen 14
S Parametrisierte jUnit 5-Tests mit eigenen Datentypen/Klassen-Objekten als Test-Parameter Allgemeine Java-Themen 0
K Input/Output JUnit: Log Inhalte, falsche Assertion Allgemeine Java-Themen 2
H OOP Testen einer Exception mit JUnit Allgemeine Java-Themen 8
AssELAss Junit-Tests für SQL-Veribindung sowie SQL-Queries? Allgemeine Java-Themen 3
O Maven - JUnit - H2 Allgemeine Java-Themen 1
M Selenium JUnit Tests (Auswahl von Testmethoden auswerten) Allgemeine Java-Themen 5
C JUNIT - ANT - build.xml Allgemeine Java-Themen 0
Airwolf89 JUnit: Vorschläge/ Best Practice Allgemeine Java-Themen 7
M JUnit Serverseitig? Wie geht sowas? Allgemeine Java-Themen 2
E JUnit wie Testergebnisse pro Test ("Test Report") erhalten? Allgemeine Java-Themen 1
B JUnit Zufalls Operation testen Allgemeine Java-Themen 1
P JUnit Allgemeine Java-Themen 2
B jUnit 4: Wie protokolliert man Testergebnisse? Allgemeine Java-Themen 1
H JUnit Fehler beim Compilieren - erledigt Allgemeine Java-Themen 0
M JUnit Test Suites Allgemeine Java-Themen 2
L JUnit - automatisiertes vs. manuelles Testen? Allgemeine Java-Themen 6
B Hilfe bei JUnit Test Allgemeine Java-Themen 1
M JUnit & Multithreading - sehr seltener Fehler Allgemeine Java-Themen 3
A JUnit/Hashcode Problem Allgemeine Java-Themen 5
X Problem mit URLClassLoader und JUnit Allgemeine Java-Themen 3
N JUnit Allgemeine Java-Themen 13
M Junit Tests durchführen Allgemeine Java-Themen 18
M JVM Probleme JUnit Allgemeine Java-Themen 2
G NUnit Features in JUnit Allgemeine Java-Themen 2
darekkay (JUnit) Testdaten generieren - Framework? Allgemeine Java-Themen 2
A JUnit problem Allgemeine Java-Themen 9
T Organisation von Junit Testfällen? Allgemeine Java-Themen 2
M JUnit Tests vs. DBUnit Tests Allgemeine Java-Themen 3
P Klassen Junit test funktioniert nicht... Allgemeine Java-Themen 11
S Die Zeile die JUnit gerade ausführt lesen Allgemeine Java-Themen 15
aze JUnit: Testen ob bestimmte Exception nicht auftritt Allgemeine Java-Themen 18
U Fehler: Hauptklasse org.junit.runner.JUnitCore konnte nicht gefunden oder geladen werden Allgemeine Java-Themen 2
G JUnit Test Methoden in anderen Thread verlagern Allgemeine Java-Themen 4
J JUnit-Tests Zeichensatzproblem ? Allgemeine Java-Themen 2
J JUnit, TestCase vs "einfacher" Test Allgemeine Java-Themen 3
S [JUnit] Name von TestCase bekommen Allgemeine Java-Themen 4
1 JUnit Test Suit Allgemeine Java-Themen 2
T Junit-Tests in Java Klasse ausführen Allgemeine Java-Themen 26
J JUnit - werfen von Exceptions testen Allgemeine Java-Themen 17
M JUnit TestSuite erstellen Allgemeine Java-Themen 2
B JUnit und mehrere Instanzen der selben Applikation Allgemeine Java-Themen 4
G Testcases mit Junit auf private-Methode Allgemeine Java-Themen 7
G Input/Output System.in "umbiegen" für junit-Test Allgemeine Java-Themen 4
C JUnit und das Zulassen von RuntimeExceptions Allgemeine Java-Themen 5
ruutaiokwu junit mit annotations geht nicht? Allgemeine Java-Themen 5
T JUnit-Log auslesen Allgemeine Java-Themen 13
C JUnit Tests Allgemeine Java-Themen 4
fastjack JUnit Supplementary Classes Allgemeine Java-Themen 4
O Junit Reports / Logs als XML ohne Maven/Ant Allgemeine Java-Themen 7
M Junit und Mocks Allgemeine Java-Themen 5
fastjack jUnit und Test von equals, hashCode, toString Allgemeine Java-Themen 11
D junit - frage zu fixtures/test suites Allgemeine Java-Themen 11
A Seltsames Verhalten von JUnit-Tests im Zusammenspiel mit Ant Allgemeine Java-Themen 6
S JUnit: Erzeugen einer IOException Allgemeine Java-Themen 9
G JUnit Tests Allgemeine Java-Themen 7
G JUnit Test Allgemeine Java-Themen 5
S JUnit - was mocken, was nicht? Allgemeine Java-Themen 3
S JUnit TesSuite und @Repeat Allgemeine Java-Themen 2
S JUnit Tests für GUI / Oberflächen Allgemeine Java-Themen 2
M Junit und Mocks bei JDBC Daos Allgemeine Java-Themen 8
M JUnit Problem mit AssertionFailedError Allgemeine Java-Themen 2
B Testfälle mit JUnit Allgemeine Java-Themen 4
S JUnit Allgemeine Java-Themen 15
N ClassNotFound Exception bei JUnit Test? Allgemeine Java-Themen 2
G ANT Tutorial . Schritte bzgl. Junit Bibliothek Allgemeine Java-Themen 4
A JUnit Reports zu groß für XSLT Allgemeine Java-Themen 4
M JUnit und dynamische Tests Allgemeine Java-Themen 11
P JUnit unter Eclipse: Problem mit Exception Allgemeine Java-Themen 8
GilbertGrape Warum schlägt JUnit-Test fehl? Allgemeine Java-Themen 19
K Bekomme JUnit TEst nicht zum laufen :( Allgemeine Java-Themen 9
K Junit: Frage zum Ablauf Allgemeine Java-Themen 3
K JUnit: Tests über ant aufrufen Allgemeine Java-Themen 2
S JUnit und EasyMock Allgemeine Java-Themen 7
B Wie alt ist JUnit? Allgemeine Java-Themen 2
A Junit Exceptions testen Allgemeine Java-Themen 3
P Testen mit JUnit Allgemeine Java-Themen 8
G Ant + JUnit Allgemeine Java-Themen 2
F JUnit unter Ant Allgemeine Java-Themen 3
S Integer zu int konvertieren - JUnit Allgemeine Java-Themen 12
G testen mit JUnit? Allgemeine Java-Themen 3
K JUnit 4 User Interaktion Allgemeine Java-Themen 7
M Ant + Junit + Testclass in Jar Allgemeine Java-Themen 3
G Junit 4 - TestSuite Allgemeine Java-Themen 6
B JUnit Allgemeine Java-Themen 2
T CheckStyle, JUnit und FindBugs aus Java-Programm starten Allgemeine Java-Themen 2
S JUnit will ins Netz! Allgemeine Java-Themen 2
B JUnit - Gleichen Test x-mal durchlaufen Allgemeine Java-Themen 2
F Hilfe: Adjazenzmatrix mittels JUnit testen. Allgemeine Java-Themen 2
H JUnit Allgemeine Java-Themen 5
N Problem mit Ant und JUnit Allgemeine Java-Themen 5

Ähnliche Java Themen

Neue Themen


Oben