Sommige coverage tools kunnen aangeven welke test welke code raakt, daar is wel degelijk een bepaalde JUnit integratie voor nodig.
[...]
Ik wil jou wel eens een testsuite zien maken subclasses waar je de instantie niet mag meegeven via de constructor want je wilt alle testxxx methodes uitvoeren en niet laten aankomen op een runtest. Het is een algemeen bekend fout dat junit je daar in de steek laat.
JUnit voert inderdaad met runtest allee testxxx methodes één voor één uit, of maar één specifieke testxxx als je dit aangeeft. Wat je bedoelt met de instantie via de constructor snap ik niet.
[...]
Komen we aan bij mijn andere kreet:
wat niet makkelijk is, bestaat niet.
Als ik in de praktijk te veel zaken moet doen om een simpele test te verrichten, dan doe ik het niet. Simpel as that. En alles wat ik niet doe, kan net zo goed niet bestaan.
Op zich vind ik het wel interessant waarom dat frameworks als virtualmock bestaan, en welke conclusie die makers zelf verbinden aan het gebruik hiervan. Je weet pas dat een oplossing niet simpel is op het moment dat je inzicht hebt in de inspanning en complexiteit die er voor nodig is. Ipv zelf het wiel uit te vinden is het makkelijker om op basis van bestaande frameworks te concluderen dat AOP/bytecode modificatie in unit tests waarschijnlijk overkill is. Wat niet makkelijk is, bestaat voor mij wel, zodat ik daarvan leer dat ik het niet moet doen, en waarom niet.
[...]
Sorry.. totaal onzin. *moppelt iets over interfaces en instanties van die interfaces en tests op stellen voor interfaces*.
Volgens mij test jij je subclasses ook niet want je komt niet met praktische oplossingen aan.
Als je schrijft dat iets onzin is, schrijf er dan ook bij waarom, dan kan ik er verder op ingaan. Subklasses geïsoleerd testen van de superklasse kan met bytecode modificatie of redesign naar een compositie. Dat zijn de enige twee manieren om het te doen, onafhankelijk van het framework wat je verder gebruikt.
Het ándere probleem wat je noemt: tests op stellen voor interfaces, is in principe een iets subtieler probleem. Unit Tests zijn namelijk white-box tests, dus je test met kennis van code in je test. Aangezien in interfaces geen code zit ga je deze niet testen, maar schrijf je aparte testcases voor je verschillende implementaties van die interface. Een beetje flauw antwoord natuurlijk, en om je niet helemaal woest te maken geef ik je toch een oplossing hoe je dit in JUnit kunt doen:
Interface:
code:
1
2
3
4
5
6
7
| package foo;
public interface Foo {
public void bar(String bla);
} |
Testcase:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| package foo;
import junit.framework.TestCase;
public class FooTest extends TestCase {
public static interface FooFactory {
public Foo createFoo();
}
private Foo foo;
private FooFactory fooFactory;
public void setFooFactory(FooFactory fooFactory) {
this.fooFactory = fooFactory;
}
@Override
protected void setUp() throws Exception {
super.setUp();
foo = fooFactory.createFoo();
}
public void testBar() {
foo.bar("bla");
}
} |
Testsuite:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| package foo;
import java.util.Enumeration;
import junit.framework.Test;
import junit.framework.TestSuite;
public class FooTests {
public static Test suite() {
TestSuite suite = new TestSuite("Tests for Foo interface");
suite.addTest(createFooTestSuite(new FooTest.FooFactory() {
public Foo createFoo() {
return new FooImpl("bla bla", 2);
}
}));
suite.addTest(createFooTestSuite(new FooTest.FooFactory() {
public Foo createFoo() {
return new FooImpl2("foo foo", 2.4d);
}
}));
return suite;
}
private static Test createFooTestSuite(FooTest.FooFactory fooFactory) {
TestSuite fooImplTestSuite = new TestSuite(FooTest.class);
Enumeration fooImplTestEnum = fooImplTestSuite.tests();
while (fooImplTestEnum.hasMoreElements()) {
((FooTest) fooImplTestEnum.nextElement()).setFooFactory(fooFactory);
}
return fooImplTestSuite;
}
} |
Als je dit allemaal wat vriendelijker wilt maken kun je ook zelf een subklasse maken van TestCase of TestSuite, en/of het combineren met generics en andere fancy dingetjes. Wie weet, als je op internet zoekt, vind je al zoiets van anderen. Dan hoef je geen nieuw framework te leren, tools te zoeken, build routines aan te passen enz. Een kreet van mij: if it isn't broke, don't fix it.
[
Voor 5% gewijzigd door
misfire op 16-05-2005 14:49
]
:strip_exif()/u/31626/eend.gif?f=community)
