[ Voor 5% gewijzigd door .oisyn op 03-06-2004 15:28 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik heb snel even een voorbeeldje in elkaar geplakt voor een stack een hierin worden een aantal methoden getest (niet allemaal want het is een voorbeeld:
Alarmnummer: Mja, dit zegt een beetje weinig. Misschien moet je een simpeler voorbeeld kiezen en even uitleggen wat je nou precies aan het testen bent, ipv een copy-paste uit je prolog compiler
)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
| class StackTestCase extends TestCase{
private Stack _stack = new Stack();
public StackTestCase(String fixture){
super(fixture);
}
public void test_pop_fromEmptyStack(){
try{
_stack.pop();
fail("EmptyStackException expected");
}catch(EmptyStackException ex){
}
}
public void test_pop_fromNonEmptyStack(){
Object item = "bla";
_stack.push(item);
Object foundItem = _stack.pop();
assertSame(item,foundItem);
assertTrue(_stack.isEmpty());
}
public void test_isEmpty_onNonEmptyStack(){
_stack.push("onzin);
assertFalse(_stack.isEmpty());
}
public void test_isEmpty_onEmptyStack(){
assertTrue(_stack.isEmpty());
}
} |
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| <target name="test.run" depends="clean,compile.core,compile.parser" description="Tests sourcefiles against answerfiles"> <mkdir dir="${classes.junit}"/> <javac srcdir="${src.run-test}" debug="on" destdir="${classes.junit}" source="1.5"> <classpath> <pathelement path="${classes.core}"/> <pathelement path="${classes.parser}"/> <fileset dir="${lib}"> <include name="**/*.jar"/> </fileset> <fileset dir="${test-lib}"> <include name="**/*.jar"/> </fileset> </classpath> </javac> <mkdir dir="${junit-reports}"/> <junit haltonerror="yes" fork="on" printsummary="on"> <classpath> <pathelement path="${classes.core}"/> <pathelement path="${classes.parser}"/> <pathelement path="${classes.junit}"/> <fileset dir="${lib}"> <include name="**/*.jar"/> </fileset> <fileset dir="${test-lib}"> <include name="**/*.jar"/> </fileset> </classpath> <formatter type="plain"/> <jvmarg value="-ea"/> <jvmarg value="-Xbootclasspath/p:${jsr14.home}/gjc-rt.jar"/> <batchtest todir="${junit-reports}"> <fileset dir="${src.run-test}"> <include name="**/*TestSuite.java"/> </fileset> </batchtest> </junit> </target> |
[ Voor 45% gewijzigd door Alarmnummer op 03-06-2004 15:58 ]
a) je hebt nog niet veel ervaring
Kijk eens naar die unit test. Is die ingewikkeld? Het stel echt niet veel voor hoor? En als je je scripts een beetje goed instelt dan is zelfs het draaien een peuleschil.
Eigelijk alles wat niet triviaal is zou je kunnen unit testen. Als jij kan garanderen dat je weinig fouten in je code hebt, dan is unit testen misschien niet voor jou. Maar ik en de andere developers zijn it-ers van vlees en bloed. En wij maken gewoon fouten. Sommige fouten zijn ongelovelijk stom, maar je hebt ook veel gecompliceerdere fouten. Op het moment dat je een groot systeem hebt met veel complexiteit, dan is het een drama om een bug op te sporen omdat die op veel punten kan zijn ontstaan. Met unit testen kan je voor subsystemen zeggen dat de kans redelijk klein is dat de fout daar is ontstaan omdat die getest zijn. Hierdoor kan je je op een kleiner gebied concentreren om de bug te achterhalen. In de praktijk is het trouwens niet altijd even eenvoudig hoor
Zelfs subsystemen kunnen met goed unit testen nog fouten veroorzaken en dan is het nog steeds lastig om te achterhalen waar de bug zit. Maar als je toch moet debuggen, dan wil ik hier in de toekomst ook een meerwaarde van hebben, en dat heb je alleen met unittesten en niet met een debugger/printlines.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
"Ik heb zo veel soep gegeten, dat kan een mens niet aan. Ik heb zo veel soep gegeten, kan bijna niet meer staan. Ik zat daar maar te slurpen achter die grote kop en als ik bijna klaar was, dan schepten ze weer op!" (Hans Teeuwen)
a) ik ben pas 2jr ing informaticus:
[...]
a) je hebt nog niet veel ervaring
b) je bent goddelijk
c) je liegt
Ja die is ingewikkeld. Maar dat zal wel met de ingewikkeldheid van je applicatie te maken hebben. Maar ik zie zeker voordelen in unit-testen, vooral als form van documentatie. Daarnaast denk ik dat het zorgvuldig en tijdig testen van delen van een systeem uiteindelijk zal leiden tot een beter systeem, en dan bedoel ik qua ontwerp en niet alleen omdat er minder bugs in zullen zitten.
Jij denkt dus dat ik alleen bezig ben met triviale dingen?
Dat heb ik niet gezegd
Jij vroeg wat je allemaal moest testen. En ik zeg: alles wat niet triviaal is (dus geen getters en setters). Alles waar een klein beetje complexiteit in zit (in principe al dat stackvoorbeeld) 'moet' geunit test worden.
[ Voor 3% gewijzigd door Alarmnummer op 03-06-2004 22:46 ]
Jij hebt dus geen bugs in je code? Jij pas nooit je functies aan?
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Ff kijken of je gelijk hebt...:
[...]
Jij hebt dus geen bugs in je code? Jij pas nooit je functies aan?
Als je je unit tests al hebt, hoef je ze na het bugfixen van bugs niet aan te passen en kan je de tests gebruiken om je bugfix te testen. Zeker met complexere code levert het uiteindelijk tijdwinst op.
Overigens vraag je hoe een aantal gevalen te unit testen. Unit testen doe je op losse functies en methods. Die hebben allemaal pre en post condities. Daar test je dus op.
En als je bij jou voorbeeld 2 (wachtwoord generatie) niet een unit test kan schijven in minder tijd dan waarin je je wachtwoord functie hebt geschreven dan is er denk ik iets mis
De rest van je voorbeelden (op 1 na) beschrijven allemaal meerdere gevallen i.p.v. 1 losse method.
Visuele dingen kan je niet unit testen nee, dus dat wordt wat moeilijk. Maar zodra je een functie of method hebt met een input die dan een bepaalde output waarde moet hebben dan is het unit testen in principe vrij makkelijk. Eenmaal je unit tests geschreven en je hebt er daarna alleen maar tijdwinst door als de functies / methods aangepast zijn. Je hoeft dan niet meer handmatig te testen.
Unit tests zijn niet noodzakelijk, ze zijn alleen handig en kunnen de ontwikkeltijd verminderen doordat je sneller je componenten kunt testen (nagaan of ze correct werken) als je er veranderingen aan gedaan hebt.
Wat heeft een command window ermee te maken?
https://fgheysels.github.io/
Mooi, dan zijn unit tests er dus makkelijk voor te schrijven
Je kan prima een unit test schrijven die 2 keer je passwoord generatie functie aanroept, en deze twee passworden vergelijkt.
Ah... sue me. Ik maak wel eens fouten in mijn code. Er zitten wel eens bugs in mijn functies ook al denk ik dat ze goed werken. En af en toe doe ik zelfs wat optimalisaties
Tuurlijk kan je ook asserts gebruiken, maar zorg je er dan wel voor dat je die asserts weer netjes uitzet op het moment dat je uitlevert aan een klant? Het zou niet de eerste keer zijn dat ik, zelfs in "goed" werkende software de asserts voorbij zie vliegen op de commandline.
[ Voor 18% gewijzigd door Creepy op 04-06-2004 09:23 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Verwijderd
Wij hebben daarvoor ServerTestCase (http://www.junit.org/junit/download/ServerTestCase.zip , via die link van Alarmnummer wel te vinden). Je moet dan de ServerTestCase tests deployen naar de server, en via een session layer aanroepen. Het resultaat/fout wordt dan mooi doorgegeven naar de cliënt.
)Reporter: Mister Gandhi, what do you think of western civilisation?
Gandhi: I think it would be a good idea
Dus hoeveel je hebt afgetest.
nope
Als ik met wat complexere zaken bezig ben dan draai ik alleen maar unit testen (ik compileer dan niet eens). Dus een nachtelijke test is leuk.. maar niet voldoende.
Ik heb clover wel eens gebruikt.Ander leuke plugin is de jcoverage die aangeeeft hoeveel 'dekking' je met je junit testjes hebt bereikt op je code.
ant test.all vind ik ook snel genoeg
Kan wel zijn.. maar de standaard is ANT en ik werk bij een bedrijf waar dit ook de standaard is.. nouja... als ze er dan ook echt gebruik van maken zoals het hoort.. Maar ANT is (helaas) de standaard.. en probeer me daar maar aan te houden.Nog een note voor TS: maven kan jou geliefde build files zelfs genereren!
[ Voor 11% gewijzigd door Alarmnummer op 30-11-2004 21:32 ]
Naasten testen op crashes e.d. valt er nog veel meer te testen hoor
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
:strip_exif()/u/31626/eend.gif?f=community)
:strip_icc():strip_exif()/u/90566/woovi-logo-clean_klein.jpg?f=community){kind=logo}
:strip_exif()/u/33970/hans.gif?f=community)
:strip_exif()/u/26373/anim4.gif?f=community)
/u/92525/me.png?f=community)
:strip_exif()/u/53488/prince.gif?f=community)
:strip_icc():strip_exif()/u/26699/usericon.jpg?f=community)
:strip_icc():strip_exif()/u/44529/800V.jpg?f=community)
:strip_icc():strip_exif()/u/2626/nice_eye.jpg?f=community)
/u/13464/Delphi.png?f=community)