 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Peter Büttner
Guest
|
 Posted: Fri May 11, 2007 4:12 am Post subject: JUnit: Listen von Daten als Einzeltests? |
 |
|
Hi
Ich habe nun mal JUnit aufgemacht, bin also darin eher Anfänger.
Was ich nicht finde ist wie man eine Liste von Eingabedaten abarbeitet,
wobei der Test nicht beim ersten Problem abbrechen soll sondern
weiterlaufen. Ich denke ich brauche dafür mehrere Tests. Nun will ich
aber nicht für jede Möglichkeit eine Methode schreiben - das wäre Quatsch.
Also sowas wie:
private static String[] toBeOk = {
"type(123)",
"type(dada(123)foo(3223))" ,
"dada(123)foo(3223)" ,
"type(dada(123)foo(du(3223)bar(dd)))" ,
"type(dada(213)foo(du(3223)bar(dd(sys(123)))))",
"isEmpty()" ,
"()" ,
"(123)" ,
"dada()()" ,
};
nacheinander an einen Parser verfüttern.
Im Moment habe ich es in einer Schleife, das würde aber beim ersten
abbrechen.
Sowas kommt soch sicher öfters vor, das man eine Reihe von Objekten
an eine zu testende Methode übergeben will. Ich find' nix dazu.
Grüße
Peter |
|
| Back to top |
|
 |
Ingo R. Homann
Guest
|
| Posted: Fri May 11, 2007 7:13 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Hi,
Peter Büttner wrote:
| Quote: | Was ich nicht finde ist wie man eine Liste von Eingabedaten abarbeitet,
wobei der Test nicht beim ersten Problem abbrechen soll sondern
weiterlaufen. Ich denke ich brauche dafür mehrere Tests. Nun will ich
aber nicht für jede Möglichkeit eine Methode schreiben - das wäre Quatsch.
Also sowas wie:
private static String[] toBeOk = {
"type(123)",
"type(dada(123)foo(3223))" ,
"dada(123)foo(3223)" ,
"type(dada(123)foo(du(3223)bar(dd)))" ,
"type(dada(213)foo(du(3223)bar(dd(sys(123)))))",
"isEmpty()" ,
"()" ,
"(123)" ,
"dada()()" ,
};
nacheinander an einen Parser verfüttern.
Im Moment habe ich es in einer Schleife, das würde aber beim ersten
abbrechen.
Sowas kommt soch sicher öfters vor, das man eine Reihe von Objekten
an eine zu testende Methode übergeben will. Ich find' nix dazu.
|
Wie wär's mit etwas anderer Syntax?:
testsuite.add(new JUnitTestType(123));
testsuite.add(new JUnitTestType(data(123),foo(3223)));
testsuite.add(dada(123),foo(3223);
....
Wozu einen Parser schreiben, wo javac schon einen hat? :-)
Ciao,
Ingo |
|
| Back to top |
|
|
Patrick Roemer
Guest
|
| Posted: Fri May 11, 2007 4:18 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Responding to Ingo R. Homann:
| Quote: | Peter Büttner wrote:
Was ich nicht finde ist wie man eine Liste von Eingabedaten abarbeitet,
wobei der Test nicht beim ersten Problem abbrechen soll sondern
weiterlaufen. Ich denke ich brauche dafür mehrere Tests. Nun will ich
aber nicht für jede Möglichkeit eine Methode schreiben - das wäre Quatsch.
Also sowas wie:
private static String[] toBeOk = {
"type(123)",
"type(dada(123)foo(3223))" ,
"dada(123)foo(3223)" ,
"type(dada(123)foo(du(3223)bar(dd)))" ,
"type(dada(213)foo(du(3223)bar(dd(sys(123)))))",
"isEmpty()" ,
"()" ,
"(123)" ,
"dada()()" ,
};
nacheinander an einen Parser verfüttern.
Im Moment habe ich es in einer Schleife, das würde aber beim ersten
abbrechen.
Sowas kommt soch sicher öfters vor, das man eine Reihe von Objekten
an eine zu testende Methode übergeben will. Ich find' nix dazu.
Wie wär's mit etwas anderer Syntax?:
testsuite.add(new JUnitTestType(123));
testsuite.add(new JUnitTestType(data(123),foo(3223)));
testsuite.add(dada(123),foo(3223);
...
Wozu einen Parser schreiben, wo javac schon einen hat? 
|
Genau. Der Vorteil dieses Vorschlags ist darueberhinaus, dass man den
eigenen Parser, und somit die Tests, ueberhaupt nicht mehr braucht, und
sich einen schoenen Nachmittag machen kann. ;)
Aber prinzipiell hast Du recht, ich wuerde das auch mit einer eigenen
Test-Implementierung erschlagen. (Ich bin etwas aus JUnit raus, das
folgende ist mit Vorsicht zu geniessen und auf JUnit < 5 bezogen.)
Leider kann man von TestCase nicht vernuenftig erben, weil da das
abstrakte Konzept von "fuehre einen Test gegen ein Result aus" herzlich
mit der "erstelle einen Test aus einer Methode"-Konvention vermixt ist -
habe ich nie verstanden, warum das nicht besser getrennt wurde.
Also mal naiv von TestCase geklaut (geht sicher besser):
public class ParserTestCase implements Test {
private String _data;
public ParserTestCase(String data) {
_data = data;
}
public int countTestCases() {
return 1;
}
public void run(TestResult result) {
result.startTest(this);
Protectable p= new Protectable() {
public void protect() throws Throwable {
runBare();
}
};
result.runProtected(this, p);
result.endTest(this);
}
private void runBare() {
// hier der eigentliche Parsertest gegen _data
}
}
Damit sollte dann sowas gehen:
String[] testData = { /* ... */ };
TestSuite suite = new TestSuite();
for (int i = 0; i < testData.length; i++) {
suite.addTest(new ParserTestCase(testData[i]));
}
return suite;
Viele Gruesse,
Patrick |
|
| Back to top |
|
|
Ingo R. Homann
Guest
|
| Posted: Fri May 11, 2007 5:06 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Hi,
Patrick Roemer wrote:
| Quote: | Wozu einen Parser schreiben, wo javac schon einen hat? :-)
Genau. Der Vorteil dieses Vorschlags ist darueberhinaus, dass man den
eigenen Parser, und somit die Tests, ueberhaupt nicht mehr braucht, und
sich einen schoenen Nachmittag machen kann. 
|
Mag sein, dass ich Peter falsch verstanden hatte. Ich hatte den
Eindruck, er wollte die Klassen/Methoden "type", "dada", "foo", "bar"
etc testen, und nicht einen Parser. Ich hatte den Eindruck, dass er nur
nicht wusste, wie er die verschiedenen Aufrufe dieser Methoden "einfach"
in mehrere Unit-Tests verpacken soll.
Wenn es aber wirklich darum geht, den Parser zu testen, dann ist es ja
noch leichter:
testsuite.add(new ParserTest("type(123)"));
testsuite.add(new ParserTest("type(dada(123)foo(3223))"));
testsuite.add(new ParserTest("dada(123)foo(3223)"));
testsuite.add(new ParserTest("type(dada(123)foo(du(3223)bar(dd)))"));
....
Ciao,
Ingo |
|
| Back to top |
|
|
Patrick Roemer
Guest
|
| Posted: Fri May 11, 2007 5:10 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Responding to Ingo R. Homann:
| Quote: | Mag sein, dass ich Peter falsch verstanden hatte. Ich hatte den
Eindruck, er wollte die Klassen/Methoden "type", "dada", "foo", "bar"
etc testen, und nicht einen Parser. Ich hatte den Eindruck, dass er nur
nicht wusste, wie er die verschiedenen Aufrufe dieser Methoden "einfach"
in mehrere Unit-Tests verpacken soll.
|
Oh, ok, auf die Idee bin wiederum ich nicht gekommen. Aber
| Sowas kommt soch sicher öfters vor, das man eine Reihe von Objekten
| an eine zu testende Methode übergeben will.
passt wohl eher zu meiner Interpretation.
| Quote: | Wenn es aber wirklich darum geht, den Parser zu testen, dann ist es ja
noch leichter:
testsuite.add(new ParserTest("type(123)"));
testsuite.add(new ParserTest("type(dada(123)foo(3223))"));
testsuite.add(new ParserTest("dada(123)foo(3223)"));
testsuite.add(new ParserTest("type(dada(123)foo(du(3223)bar(dd)))"));
...
|
Genau. Wobei mich halt nur wundert, dass es keine "schoene" Basisklasse
fuer ParserTest gibt, die ohne unnoetigen Ballast daherkommt. Oder
uebersehe ich die nur?
Viele Gruesse,
Patrick |
|
| Back to top |
|
|
Ingo R. Homann
Guest
|
| Posted: Fri May 11, 2007 6:08 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Hi,
Patrick Roemer wrote:
| Quote: | Wenn es aber wirklich darum geht, den Parser zu testen, dann ist es ja
noch leichter:
testsuite.add(new ParserTest("type(123)"));
testsuite.add(new ParserTest("type(dada(123)foo(3223))"));
testsuite.add(new ParserTest("dada(123)foo(3223)"));
testsuite.add(new ParserTest("type(dada(123)foo(du(3223)bar(dd)))"));
...
Genau. Wobei mich halt nur wundert, dass es keine "schoene" Basisklasse
fuer ParserTest gibt, die ohne unnoetigen Ballast daherkommt. Oder
uebersehe ich die nur?
|
Die BasisKlasse dafür heisst "TestCase" und die Klasse ParserTest ist
vermutlich ein 5-Zeiler. ;-)
Ciao,
Ingo |
|
| Back to top |
|
|
Patrick Roemer
Guest
|
| Posted: Fri May 11, 2007 7:37 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Responding to Ingo R. Homann:
| Quote: | testsuite.add(new ParserTest("type(123)"));
testsuite.add(new ParserTest("type(dada(123)foo(3223))"));
testsuite.add(new ParserTest("dada(123)foo(3223)"));
testsuite.add(new ParserTest("type(dada(123)foo(du(3223)bar(dd)))"));
...
Genau. Wobei mich halt nur wundert, dass es keine "schoene" Basisklasse
fuer ParserTest gibt, die ohne unnoetigen Ballast daherkommt. Oder
uebersehe ich die nur?
Die BasisKlasse dafür heisst "TestCase" und die Klasse ParserTest ist
vermutlich ein 5-Zeiler.
|
Das mag zur Not eine Basisklasse dafuer sein, bestimmt aber keine
"schoene" solche, die ohne unnoetigen Ballast daherkommt. Schreib den
Fuenfzeiler mal, und Du wirst (hoffentlich) sehen, was ich meine. :)
Viele Gruesse,
Patrick |
|
| Back to top |
|
|
Peter Büttner
Guest
|
| Posted: Sat May 12, 2007 4:23 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Patrick Roemer wrote:
| Quote: |
Responding to Ingo R. Homann:
testsuite.add(new ParserTest("type(123)"));
[...]
...
|
Und natürlich will ich eine Implementierung gegen eine reihe Daten testen,
dachte es wäre klar, aber man kann es auch anders verstehen wenn man nicht
weis wieviel der Frager weis - ist wohl die Regel:-)
Ich hatte zuerst Test implementiert und das naiv gestartet, bricht halt
nach Exception ab. Das Protectable hab' ich zwar wahrgenommen, aber nicht
so recht. Und diese 'komische' implementierung von TestCase ist auch nicht
verständnisfördernd.
Ah, bevor ichs vergesse: junit-3.8.1
| Quote: | Genau. Wobei mich halt nur wundert, dass es keine "schoene" Basisklasse
fuer ParserTest gibt, die ohne unnoetigen Ballast daherkommt. Oder
uebersehe ich die nur?
|
Meins (Patricks code):
public abstract class ProtectedSimpleTest implements Test{
public int countTestCases() {return 1;}
public final void run(TestResult result) {
result.startTest(this);
Protectable p= new Protectable() {
public void protect() throws Throwable {
runBare();
}
};
result.runProtected(this, p);
result.endTest(this);
}
protected abstract void runBare();
}
| Quote: | Die BasisKlasse dafür heisst "TestCase" und die Klasse ParserTest ist
vermutlich ein 5-Zeiler.
|
Auf junit.org steht irgendwo das Framework sollte einfach sein. Aber das
TestCase und die methode per reflection so verheiratet sind scheint mir
ein Anfängerfehler. Auch wenn ich mich gerade lächerlich mache: das ist
schlecht implementiert. Es wäre doch ganz einfach runTest() in eine
eigene Klasse zu stopfen und TestCase als Basis für eigene Implementierungen
anzubieten.
Ist ein bischen sparsam geraten, imho. Ein kleines Rudel sinnvoller
kleiner Basisimplementierungen fände ich (auf den ersten Blick) besser.
Klar kann man das per copy&paste selbst bauen, aber es ist doch ärgerlich
wenn man eigenen Frameworkcode in alle Projekte mitschleifen muß. Oder wenn
man extensions zu jUnit verwendet.
| Quote: | Das mag zur Not eine Basisklasse dafuer sein, bestimmt aber keine
"schoene" solche, die ohne unnoetigen Ballast daherkommt. Schreib den
Fuenfzeiler mal, und Du wirst (hoffentlich) sehen, was ich meine.
|
Was wäre das Problem nur
protected void runTest()
zu überschreiben? Wobei es kaum was bringt, der Rest macht fast nix,
ausser das der Rest besser zu passt.
Ich hab' mal die API Doku zu jUnit4 angesehen. Soweit ich das sehe stützt
es sich nur auf annotations, und sowas wie oben geht gar nicht mehr?
Es gibt kein interface Test und TestSuit mehr.
Grüße
Peter |
|
| Back to top |
|
|
Peter Büttner
Guest
|
| Posted: Tue May 15, 2007 3:30 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Patrick Roemer wrote:
| Quote: | Responding to Volker Glave:
Was ich nicht finde ist wie man eine Liste von Eingabedaten abarbeitet,
wobei der Test nicht beim ersten Problem abbrechen soll sondern
weiterlaufen.
Hm, aber ja doch, genau so ist das doch, bei der ersten auftretenden
Abweichung gilt der Testfall als nicht erfüllt.
Jedes Eingabedatum repraesentiert einen eigenstaendigen Testfall.
|
So einfach hätte ich es kaum beschreiben können:-)
Grüße
Peter |
|
| Back to top |
|
|
Peter Büttner
Guest
|
| Posted: Tue May 15, 2007 3:48 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Patrick Roemer wrote:
| Quote: | Responding to Ingo R. Homann:
|
| Quote: | class ParserTest extends TestCase {
String s;
ParserTest(String s) {this.s=s;setName(s);}
void test() {
assertEquals(s,new MyParser().parse(s).toString());
}
|
| Quote: | Das ist kaputt. 'Richtig' waere: 'this.s=s; setName("test");'. Und wenn
Dir dieser Anblick nicht auf Anhieb Schmerzen verursacht, kann ich Dich
wohl auch in laengerer Diskussion nicht ueberzeugen, dass das Mist ist. :)
Ich gehe mal davon aus, dass Du nicht die Code-Formatierung meinst
(welche ich ja nur als Scherz so verwendet hatte). Also: Was willst Du -
einen aussagekräftigeren Namen für den Test?
|
| Quote: | Nein. TestCase will den Namen der auszufuehrenden TestMethode gesetzt
haben, um diese dann per Reflection aufzurufen zu koennen, und dieser
Name ist in Deinem Beispiel nun mal "test". "pluggable selector" nennt
der Herr Beck dieses Idiom. Wenn Du dieses Verhalten loswerden
moechtest, musst Du schon irgendwas in TestCase ueberschreiben.
|
Das der name des Tests auch der Name der methode wird scheint
ja nur in:
TestCase#runTest()
verwendet zu werden. Ignoriert man das und überschreibt runTest()
sollte es ja gehen, dann kann man den testCase verwenden.
Aber wenn irgendwas sich drauf verlassen würde das der name der
methode entspricht geht's schief.
Wobei in TesCase ja auch nirgendwo verbindlich steht das der name
dem namen der methode entspricht.
Ach, s**** drauf, auch egal. Nervt mich halt so viel schlechten Code
überall zu finden.
Grüße
Peter |
|
| Back to top |
|
|
Peter Büttner
Guest
|
| Posted: Tue May 15, 2007 3:50 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Raffael Herzog wrote:
| Quote: | Peter Büttner schrieb:
Was ich nicht finde ist wie man eine Liste von Eingabedaten
abarbeitet, wobei der Test nicht beim ersten Problem abbrechen soll
sondern weiterlaufen. Ich denke ich brauche dafür mehrere Tests. Nun
will ich aber nicht für jede Möglichkeit eine Methode schreiben - das
wäre Quatsch.
evtl. hilft dir TestNG (www.testng.org) da weiter:
public class MyTest {
@Test(dataProvider="SomethingProvider")
public void testSomething(String a, Integer b) { ... }
@DataProvider(name="SomethingProvider)
Object[][] getSomething() {
return new Object[][] {
{ "foo", 42 },
{ "gar", 23 }
...
};
}
}
Das wird nun testSomething mit den Daten von getSomething() aufrufen,
bis das Array abgearbeitet ist. Man kann natürlich auch dieselben Daten
an verschiedene Test-Methoden verfüttern.
|
Sieht auch halbwegs brauchbar aus.
TestNG kann ich mir dann halt mal ansehen, wenn ich zu komme, 2010 oder so.
| Quote: | Gruss,
Raffi, der nicht nachvollziehen kann, warum die Leute noch immer das
im Vergleich zu TestNG primitiv anmutende JUnit verwenden
|
Nun, bisher hab ich zugegebnermassen mit public static main(...)
getestet. Und ja, das geht, mein Code scheint doch recht stabil zu
sein, schreiben, testen und vergessen. Naja, kommt auf's Projekt an -
aber paar Jahre alte Projekte sehen nach einem Blick rein eh' s**** aus.
Wollte nun mal qualifizierter testen (und hätte es auch an anderer
Stelle gebraucht). Also Eclipse, neuer jUnit Test und loslegen. Ausserdem
hört man zumeist von jUnit. So fängt man halt damit an.
Das Umbauen auf ein anderes testframework ist bei junit ja einfach,
was mir nämlich immer wieder ins Auge springt sind Aussagen wie
'mit wenig Framework' -- das kann man dann auch leicht ersetzen:-)
Grüße
Peter |
|
| Back to top |
|
|
Ingo R. Homann
Guest
|
| Posted: Tue May 15, 2007 7:24 am Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Hi,
Patrick Roemer wrote:
| Quote: | class ParserTest extends TestCase {
String s;
ParserTest(String s) {this.s=s;setName(s);}
void test() {
assertEquals(s,new MyParser().parse(s).toString());
}
}
Das ist kaputt. 'Richtig' waere: 'this.s=s; setName("test");'. Und wenn
Dir dieser Anblick nicht auf Anhieb Schmerzen verursacht, kann ich Dich
wohl auch in laengerer Diskussion nicht ueberzeugen, dass das Mist ist. :)
Ich gehe mal davon aus, dass Du nicht die Code-Formatierung meinst
(welche ich ja nur als Scherz so verwendet hatte). Also: Was willst Du -
einen aussagekräftigeren Namen für den Test?
Nein. TestCase will den Namen der auszufuehrenden TestMethode gesetzt
haben, um diese dann per Reflection aufzurufen zu koennen, und dieser
Name ist in Deinem Beispiel nun mal "test". "pluggable selector" nennt
der Herr Beck dieses Idiom. Wenn Du dieses Verhalten loswerden
moechtest, musst Du schon irgendwas in TestCase ueberschreiben.
|
Ich versteh' immer noch nicht, was Du willst: Solange die Methode mit
"test" beginnt, ruft die TestSuite sie (per Reflection) auch auf, egal,
ob ich irgendwo setName() aufrufe oder nicht.
| Quote: | Entschuldige bitte, dass ich den Testfall auch laufen lassen moechte.
|
Wie gesagt: Das geht sogar noch einfacher, auch ohne das setName().
Ciao,
Ingo |
|
| Back to top |
|
|
Patrick Roemer
Guest
|
| Posted: Tue May 15, 2007 2:34 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Responding to Ingo R. Homann:
| Quote: | Nein. TestCase will den Namen der auszufuehrenden TestMethode gesetzt
haben, um diese dann per Reflection aufzurufen zu koennen, und dieser
Name ist in Deinem Beispiel nun mal "test". "pluggable selector" nennt
der Herr Beck dieses Idiom. Wenn Du dieses Verhalten loswerden
moechtest, musst Du schon irgendwas in TestCase ueberschreiben.
Ich versteh' immer noch nicht, was Du willst: Solange die Methode mit
"test" beginnt, ruft die TestSuite sie (per Reflection) auch auf, egal,
ob ich irgendwo setName() aufrufe oder nicht.
|
Die TestSuite ruft sie nicht selber auf, sie sucht, so ihr eine Klasse
uebergeben wird, die Methoden lediglich zusammen und erstellt pro
Methode ein Exemplar der Testklasse und setzt bei diesem, entweder per
Konstruktor oder per setName(), den Methodennamen - zu bewundern in
TestSuite#createTest(). Der eigentliche Aufruf per Reflection erfolgt
dann in TestCase#runTest() - anhand des so gesetzten Namens.
In Deinem Beispiel kann man TestSuite aber schlecht eine Klasse
uebergeben. Wir muessen den Testfall ja schon mit dem zu testenden Datum
instantiieren, und dann dieses Exemplar uebergeben. Dann macht die Suite
aber eben gar nichts mehr, sondern erwartet, dass das Testexemplar
bereits fertig konfiguriert ist - und das heisst im Falle eines TestCase
nun mal: dass der Methodenname gesetzt ist.
IOW, wenn man #runTest() oder anderes nicht ueberschreiben will, kommt
man im konkreten Beispiel nicht umhin, im Konstruktor, von aussen, oder
sonstwo setName("test") (oder super("test")) aufzurufen. Dann
funktioniert es; es mutet aber leicht bekloppt an, explizit einen
(fixen) Methodennamen zu setzen, um die zugehoerige Methode per
Reflection aufzurufen, statt die Methode direkt aufrufen zu lassen - die
Reflectionfunktionalitaet wollen wir in diesem Fall ja eigentlich gar
nicht, sie ist schlicht im Weg. (Und diese Beschreibung ist jetzt schon
laenger als der eigentliche Code...)
Also entweder stehe ich komplett im Wald und uebersehe etwas
grundsaetzliches, oder wir reden ueber unterschiedliche JUnits (und
AFAICS ist dieses Verhalten bei 3.8 und 4.0 identisch), oder mir
erschliesst sich langsam, warum Du bei der Sache kein Problem sehen
kannst - Du schaust naemlich scheinbar gar nicht hin. ;)
Hast Du Deine unterschiedlichen hier geposteten Varianten denn mal
laufen lassen? Wenn ja, wie?
Viele Gruesse,
Patrick |
|
| Back to top |
|
|
Ingo R. Homann
Guest
|
| Posted: Tue May 15, 2007 2:41 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Hi,
Patrick Roemer wrote:
| Quote: | Also entweder stehe ich komplett im Wald und uebersehe etwas
grundsaetzliches, oder wir reden ueber unterschiedliche JUnits (und
AFAICS ist dieses Verhalten bei 3.8 und 4.0 identisch), oder mir
erschliesst sich langsam, warum Du bei der Sache kein Problem sehen
kannst - Du schaust naemlich scheinbar gar nicht hin. ;)
Hast Du Deine unterschiedlichen hier geposteten Varianten denn mal
laufen lassen? Wenn ja, wie?
|
Die Code-Beispiele, die ich hier gepostet habe, habe ich natürlich nicht
laufen lassen, weil mir ja die zu testenden Klassen fehlen.
Aber ich verwende Unit-Tests, die genau so aufgebaut sind.
Ehrlich gesagt bin ich aber jetzt zu faul, aus meinen doch recht
umfangreichen Test-Suites hier etwas kurzes, compilier- und lauffähiges
raus zu extrahieren, nur weil wir uns über eine einzige Code-Zeile streiten.
Ciao,
Ingo |
|
| Back to top |
|
|
Patrick Roemer
Guest
|
| Posted: Tue May 15, 2007 3:22 pm Post subject: Re: JUnit: Listen von Daten als Einzeltests? |
|
|
Responding to Ingo R. Homann:
| Quote: | Hast Du Deine unterschiedlichen hier geposteten Varianten denn mal
laufen lassen? Wenn ja, wie?
Die Code-Beispiele, die ich hier gepostet habe, habe ich natürlich nicht
laufen lassen, weil mir ja die zu testenden Klassen fehlen.
|
Ich bitte Dich. "assertEquals(s,new MyParser().parse(s).toString());"
durch "assertEquals(s,s);" zu ersetzen oder ganz zu loeschen sollte sich
doch gerade noch im Rahmen des Machbaren bewegen.
Wenn ich Deine bisherigen Beispiele so laufen lasse...
TestSuite suite = new TestSuite();
ParserTest test = new ParserTest("42");
suite.addTest(test);
TestRunner.run(suite);
....bekomme ich wahlweise sowas...
AssertionFailedError: TestCase.fName cannot be null
....oder sowas...
AssertionFailedError: Method "42" not found
Es sei denn, ich setze halt explizit 'setName("test");'.
| Quote: | Aber ich verwende Unit-Tests, die genau so aufgebaut sind.
|
Taete mich sehr interessieren, wie das funktionieren soll.
| Quote: | Ehrlich gesagt bin ich aber jetzt zu faul, aus meinen doch recht
umfangreichen Test-Suites hier etwas kurzes, compilier- und lauffähiges
raus zu extrahieren, nur weil wir uns über eine einzige Code-Zeile streiten.
|
Das "zu faul" vermute ich schon seit einigen Postings in diesem Thread,
ja. :)
Viele Gruesse,
Patrick |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
