[alg] Hoe zwaar testen jullie?

[Alarmnummer]

Hoe zwaar testen jullie je code?

Ik gebruik al een paar jaar unittests en ik merk dat het me niet alleen een lading tijd scheelt (ik hoef minder te debuggen), maar het geeft ook een stuk vertrouwen. Tegenwoordig maak ik behoorlijk zware unit tests en vooral met het huidige project waarmee ik bezig ben (een prolog compiler) wil je door de complexe flow van informatie, echt niet met writeln`s op zoek gaan naar je bugs. En ook al is een stuk code uiteindelijk bugvrij, er komen toch wijzigingen en daarmee kun je nieuwe bugs introduceren (zelfs in de 'bugvrije' code). De unit testen blijven altijd aanwezig en je kunt ze dus ook altijd opnieuw uitvoeren. In tegenstelling tot de debugger en de writeln`s blijven unit testen hun waarde houden.

Unit testen is een vast deel van XP en unit testen moet je volgens XP ook tot in het extreme doorvoeren. Ik zet echter mijn vraagtekens bij de X (eXtreme) van XP, maar unittesten is toch een van de uitzonderingen hierop. Unit testen vind ik persoonlijk een onmisbaar onderdeel en ze worden ook steeds zwaarder omdat ik merk dat ik er tijd mee win. Je bent idd even bezig om unit test code toe te voegen, maar dat hoeft geen al te groot probleem te zijn aangezien je met een template al een heel eind komt. Verder worden mijn test directories door ANT ook automatisch afgescanned naar *TestSuite.java bestanden zodat ik alleen maar TestSuite bestanden hoef toe te voegen aan de test directories.

Unit testen kun je op verschillende tijdstippen toevoegen. Als ik aan het prototypen ben wil ik geen blok aan mijn been in de vorm van unittests en maak ik alleen hele lichte tests als ik een stuk functionaliteit wil doorfluiten. Maar op het moment dat je van een prototype een serieus stuk software wilt maken, wordt iedere niet triviale methode grondig getests. Ik heb al zo`n enorme collectie met simpele foutjes verwijdert door unit testen, dat ik eigelijk geen software meer durf te schrijven zonder dit te testen.

Verder hoeven unit testen ook geen onfunctioneel stuk code te zijn, want eigelijk zijn ze meer waard dan documenatie. In een unittest staat namelijk exact je contract beschreven: je ziet wat een object kan en niet kan. Unit testen zijn in dat opzicht uitvoerbare documentatie.

Tot zover mijn verhaal over unit testen.. Ik wil dus graag weten wat jullie vinden van unit testen. Of jullie het gebruiken, in welke vorm en mate. Als je het niet gebruik, de argumenten waarom niet. En welke tools jullie hiervoor gebruiken.

[edit]
Ik heb het hier alleen gehad over unit testen, maar uiteraard heb je ook acceptance en integration tests. Voeren jullie deze testen ook uit, en zo ja, hoe?

[ Voor 4% gewijzigd door Alarmnummer op 28-05-2004 09:44 ]

[whoami]

Ik doe eigenlijk te weinig aan unit testen.
Op m'n werk hier, doen we er zelfs niet aan, al vind ik wel dat het een serieuze toegevoegde waarde kan hebben. We zijn hier maar met 2 ontwikkelaars, en er is niet echt tijd om unit tests uit te schrijven. Daarnaast komt er ook nog eens bij dat het design van dit project niet je van het is, en het redelijk moeilijk is om er fatsoenlijke unit-tests voor te schrijven. (Don't blame me. ).

Ik ben wel van plan om op m'n nieuw werk te gaan unit - testen (en het daar in te voeren als het nog niet gebruikt wordt).

Voor sommige thuisprojectjes heb ik al wel eens met NUnit bezig geweest om te unit-testen.

[MSalters]

Het XP-model heeft natuurlijk gratis unit-tests, dat maakt de verkoop ervan makkelijker.

[Alarmnummer]

whoami schreef op 28 mei 2004 @ 09:59:
Ik doe eigenlijk te weinig aan unit testen.
Op m'n werk hier, doen we er zelfs niet aan, al vind ik wel dat het een serieuze toegevoegde waarde kan hebben. We zijn hier maar met 2 ontwikkelaars, en er is niet echt tijd om unit tests uit te schrijven.

Je hoort idd vaak: ik heb de tijd er niet voor. In principe heb ik de tijd er ook niet voor, ik heb ook te maken met deadlines. Maar ik merk dat ik door het toevoegen van unit testen, minder tijd hoef te spenderen aan het debuggen. En het debuggen heeft alleen een tijdjelijke waarde (je haalt de huidige bugs eruit) maar het is geen garantie naar de toekomst, en dat zijn unit testen wel. In 1e instantie lijkt het dus extra werk, maar ik merk dat ik tijd bespaar.

Daarnaast komt er ook nog eens bij dat het design van dit project niet je van het is, en het redelijk moeilijk is om er fatsoenlijke unit-tests voor te schrijven. (Don't blame me. ).

Het voordeel aan unit testen is dat je ontwerp ookt testbaar gaat worden, en meestal zorgt dat dus ook voor een beter ontwerp. Je krijgt dan niet van die gecompliceerde brokken met een lastige flow, maar je krijgt goed omschreven eenheden. Je kan zelf nog een stapje verder gaan door de testcode het ontwerp te laten bepalen (Test Driven Development). Voor sommige dingen vind ik het wel praktisch, maar ik ben er (nog) niet serieus mee bezig.

[Alarmnummer]

MSalters schreef op 28 mei 2004 @ 10:06:
Het XP-model heeft natuurlijk gratis unit-tests, dat maakt de verkoop ervan makkelijker.

Hoe bedoel je? En unittesten kan binnen iedere methodologie gebruikt worden hoor, zelfs de waterval.

[whoami]

Alarmnummer schreef op 28 mei 2004 @ 10:14:
[...]

Je hoort idd vaak: ik heb de tijd er niet voor. In principe heb ik de tijd er ook niet voor, ik heb ook te maken met deadlines. Maar ik merk dat ik door het toevoegen van unit testen, minder tijd hoef te spenderen aan het debuggen. En het debuggen heeft alleen een tijdjelijke waarde (je haalt de huidige bugs eruit) maar het is geen garantie naar de toekomst, en dat zijn unit testen wel. In 1e instantie lijkt het dus extra werk, maar ik merk dat ik tijd bespaar.

Idd, ik moet je helemaal gelijk geven. Testen kan ervoor zorgen dat je minder tijd kwijt bent aan debuggen.

Het voordeel aan unit testen is dat je ontwerp ookt testbaar gaat worden, en meestal zorgt dat dus ook voor een beter ontwerp. Je krijgt dan niet van die gecompliceerde brokken met een lastige flow, maar je krijgt goed omschreven eenheden. Je kan zelf nog een stapje verder gaan door de testcode het ontwerp te laten bepalen (Test Driven Development). Voor sommige dingen vind ik het wel praktisch, maar ik ben er (nog) niet serieus mee bezig.

[/quote]
Mjah, ik heb iig geen zin om voor de tijd dat ik hier nog ben, het design van die hele applicatie te gaan omgooien. Het is nogal groot nl.....
Daarbij komt ook nog dat ik hier als laatste ben bijgekomen, en dat mijn collega ook m'n werkgever is, en dat die de applicatie eigenlijk op poten gezet heeft.

[Alarmnummer]

Ik heb op mijn site trouwens een zip geplaatst met daarin de test raporten van de prolog core. Je krijgt dan een beetje een indruk hoe ver ik ga met het testen.

[jelmervos]

Wij werken op het werk volgens de XP methode en daarbij horen natuurlijk de unit tests. Zelf vind ik een zeer goede manier voor het minimaliseren van bugs in je software.
Het nadeel is soms wel dat naarmate je systeem groter wordt je je tests ook groter moet maken. Objecten hebben vaak diverse andere objecten nodig om te kunnen werken (mock objects een oplossing???).
Verder zorgen testjes ervoor dat je logica zoveel mogelijk op 1 plaats zit, logica in je UI is namelijk niet/moeilijk te testen. Dit vind ik een zeer groot voordeel.

Wij testen zo goed als alles. Het kost in het begin tijd, maar naarmate je systeem groeit gaat het minder tijd kosten en gaat het meer opleveren.

[Alarmnummer]

Kaassoevlee schreef op 28 mei 2004 @ 10:56:
Wij werken op het werk volgens de XP methode en daarbij horen natuurlijk de unit tests. Zelf vind ik een zeer goede manier voor het minimaliseren van bugs in je software.
Het nadeel is soms wel dat naarmate je systeem groter wordt je je tests ook groter moet maken. Objecten hebben vaak diverse andere objecten nodig om te kunnen werken (mock objects een oplossing???).

Yep.. Ik maak er zelf wel vaak gebruik van als ik objecten een bepaalde functionaliteit wil geven zonder extreem moeilijk te doen. Om exceptions bv te testen maak ik soms gebruik van objecten die altijd een exceptie opwerpen.

Wij testen zo goed als alles. Het kost in het begin tijd, maar naarmate je systeem groeit gaat het minder tijd kosten en gaat het meer opleveren.

Misschien dat je deze dan kunt waarderen. Alle *TestSuite.java bestanden worden automatisch geunittest.

code:

<junit haltonerror="yes" fork="on" printsummary="on">
            <classpath>
                <pathelement path="${classes.core}"/>
                <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.core-test}">
                    <include name="**/*TestSuite.java"/>
                </fileset>
            </batchtest>
            
        </junit>

[DaCoTa]

Waar ik met unit testing tegenaan loop is het feit dat er voor een project vaak al een enorm stuk basis code is. Gemeenschappelijke utility libs, eigen ontwikkelde API's, etc. etc. De tijdwinst die mogelijk behaald kan worden door het schrijven van unit tests is voor deze code veel minder, omdat dit vaak al productie-rijpe code is, overgenomen van andere, langer lopende projecten. Hier zitten dus geen beginnersfouten meer in, omdat die er al met traditionele middelen eruit gehaald zijn. De bugs die er nog in zitten, bevinden zich dan vaak op een hoger nivo, getriggered door ander gebruik van de applicatiecode, of bugs in nog niet gebruikte code. Afijn, wat rest is dan de nieuwe code, maar dan bouw je tests op een half project en dan is het veel lastiger om een goede testsuite te bouwen.

Andere tests zitten er altijd in, altijd acceptatietests op een separate omgeving, maken (door ontwikkelaar of klant) van test datasets. Tenslotte is er voor de live-gang van code ook een bepaalde run-through voor de applicatie weer vrij gegeven wordt. Helaas was er geen budget voor een mirror uitvoering van de productieomgeving, anders was dat veel eenvoudiger geweest.

[Alarmnummer]

DaCoTa schreef op 28 mei 2004 @ 11:16:
Waar ik met unit testing tegenaan loop is het feit dat er voor een project vaak al een enorm stuk basis code is. Gemeenschappelijke utility libs, eigen ontwikkelde API's, etc. etc. De tijdwinst die mogelijk behaald kan worden door het schrijven van unit tests is voor deze code veel minder, omdat dit vaak al productie-rijpe code is, overgenomen van andere, langer lopende projecten. Hier zitten dus geen beginnersfouten meer in, omdat die er al met traditionele middelen eruit gehaald zijn.

Ik test alleen de code van het project zelf, en niet van subprojecten. Zijn het mijn eigen subprojecten dan worden ze bij het subproject getest, en bij code van een ander is het meer op hoop van zegen. Hopen dat zij ook alles getest hebben en dat er weinig bugs in zitten.

De bugs die er nog in zitten, bevinden zich dan vaak op een hoger nivo, getriggered door ander gebruik van de applicatiecode, of bugs in nog niet gebruikte code. Afijn, wat rest is dan de nieuwe code, maar dan bouw je tests op een half project en dan is het veel lastiger om een goede testsuite te bouwen.

Daar heb ik zelf gelukkig nog maar weinig problemen mee gehad. Mijn subprojecten test ik bij het subproject zelf. En de jars die gemaakt worden die test ik niet nog een keer in het superproject.

Andere tests zitten er altijd in, altijd acceptatietests op een separate omgeving, maken (door ontwikkelaar of klant) van test datasets. Tenslotte is er voor de live-gang van code ook een bepaalde run-through voor de applicatie weer vrij gegeven wordt. Helaas was er geen budget voor een mirror uitvoering van de productieomgeving, anders was dat veel eenvoudiger geweest.

Dit is iets waar ik in de toekomst ook meer aandacht aan wil besteden.

[Sybr_E-N]

Wij hebben zojuist op school een voor mij nieuwe methode geleerd om C++ programma's te testen. Door het uitvoeren van regressietesten, hiermee kun je je classes, functions ed. mee uittesten. Hierbij krijg je te maken met een testscript, een testdriver en een file met gewenste output. Door het vergelijken van de uiteindelijke output met de verwachte output kun je gaan controleren of je iets fout hebt geprogrammeerd en je kunt meteen zien waar het fout gaat.

[Donderwolk]

Ik test meestal alleen de functies waarbij ik verwacht dat het mis zou kunnen gaan. Dus tijdens het programmeren zet ik daar dan meteen al een breakpoint neer.
In de debug mode zie ik dan vanzelf wel waar m'n brakke code het laat afweten om vervolgens meteen het probleem op te lossen.

[Cavalera125]

DaCoTa schreef op 28 mei 2004 @ 11:16:
Waar ik met unit testing tegenaan loop is het feit dat er voor een project vaak al een enorm stuk basis code is. Gemeenschappelijke utility libs, eigen ontwikkelde API's, etc. etc. De tijdwinst die mogelijk behaald kan worden door het schrijven van unit tests is voor deze code veel minder, omdat dit vaak al productie-rijpe code is, overgenomen van andere, langer lopende projecten. Hier zitten dus geen beginnersfouten meer in, omdat die er al met traditionele middelen eruit gehaald zijn.

Uhmm is het hele idee achter unittests niet dat je de tests schrijft voor dat je gaat programmeren? Tenminste zo heb ik het begrepen. Acceptance tests zal bijna iedereen wel gebruiken lijkt me, dit is tenslotte het meetinstrument om te kijken of het aan de eisen voldoet.

[Alarmnummer]

Cavalera schreef op 28 mei 2004 @ 12:38:
[...]

Uhmm is het hele idee achter unittests niet dat je de tests schrijft voor dat je gaat programmeren? Tenminste zo heb ik het begrepen. Acceptance tests zal bijna iedereen wel gebruiken lijkt me, dit is tenslotte het meetinstrument om te kijken of het aan de eisen voldoet.

Dat is niet noodzakelijk. Test Driven Development (wat jij bedoelt) is niet noodzakelijk om unit tests te gebruiken.

[MSalters]

Alarmnummer schreef op 28 mei 2004 @ 10:17:
[ MSalters schreef op 28 mei 2004 @ 10:06:
Het XP-model heeft natuurlijk gratis unit-tests, dat maakt de verkoop ervan makkelijker. ]
Hoe bedoel je?

In XP zijn de unit tests tegelijkertijd de specificaties. Aangezien de baas bijna altijd specificaties wil heb je in XP dus daarmee je unit tests. De bestede tijd is dus ook geboekt op requirements schrijven, en er is geen tijd geboekt op het maken van unit tests. Dat is "dus" gratis.

[DaCoTa]

Cavalera schreef op 28 mei 2004 @ 12:38:
[...]

Uhmm is het hele idee achter unittests niet dat je de tests schrijft voor dat je gaat programmeren? Tenminste zo heb ik het begrepen.

Ja, maar het kan zijn dat je al projecten hebt lopen, voor je naar unit testing overstapt... Voor nieuwe projecten is het schrijven van tests vooraf dus de bedoeling, maar mijn vraag was dus wat je doet met code die je overneemt van een ander project, waar nog geen unit tests geschreven zijn?

Of, nog korter: hoe introduceer je unit-testing in lopende projecten?

[Alarmnummer]

DaCoTa schreef op 28 mei 2004 @ 14:03:
[...]

Ja, maar het kan zijn dat je al projecten hebt lopen, voor je naar unit testing overstapt... Voor nieuwe projecten is het schrijven van tests vooraf dus de bedoeling, maar mijn vraag was dus wat je doet met code die je overneemt van een ander project, waar nog geen unit tests geschreven zijn?

Of, nog korter: hoe introduceer je unit-testing in lopende projecten?

Dat is meestal vrij lastig omdat de code niet geschreven is met het oog op testbaarheid. Daar zul je dus eerst aan moeten werken, je code testbaar te maken.

[igmar]

Alarmnummer schreef op 28 mei 2004 @ 09:43:
Hoe zwaar testen jullie je code?

Niet zo zwaar als ik zou willen, maar wel behoorlijk.

Ik gebruik al een paar jaar unittests en ik merk dat het me niet alleen een lading tijd scheelt (ik hoef minder te debuggen), maar het geeft ook een stuk vertrouwen.

Ik ben d'r een die nog steeds in C progged (te lui om wat anders te leren, en in dit project is C wel een vereiste), dus echt unittesten is niet aan de orde (puur omdat de middelen daarvoor ontbreken). Ik maak wel losse testcases, die ik zodanig schrijf dat ze zoveel mogelijk code omvatten.

Tegenwoordig maak ik behoorlijk zware unit tests en vooral met het huidige project waarmee ik bezig ben (een prolog compiler) wil je door de complexe flow van informatie, echt niet met writeln`s op zoek gaan naar je bugs. En ook al is een stuk code uiteindelijk bugvrij, er komen toch wijzigingen en daarmee kun je nieuwe bugs introduceren (zelfs in de 'bugvrije' code). De unit testen blijven altijd aanwezig en je kunt ze dus ook altijd opnieuw uitvoeren. In tegenstelling tot de debugger en de writeln`s blijven unit testen hun waarde houden.

Ik compile standaard alles met -Wall -Werror -pedantic, en wijk daar maar in een paar situaties van af. Compiler warnings == bugs als je het mij vraagt. Verder is een goed design essentieel : Fouten onstaan en zijn moeilijk op te zoeken als je code nie modulair is opgebouwd (het is dan ook niet te testen). Verder is valgrind een essentieel onderdeel van het testen, en ik ben gaan merken dat ik steeds vaker foutloze code oplever.

Unit testen is een vast deel van XP en unit testen moet je volgens XP ook tot in het extreme doorvoeren. Ik zet echter mijn vraagtekens bij de X (eXtreme) van XP, maar unittesten is toch een van de uitzonderingen hierop.

Ik heb de XP filosofie doorgelezen, maar ben het niet met ze eens op alle punten. Dat testen echter een essentieel onderdeel is staat vast. Verder is hergebruik van code ook een sterke pre, dat spaart het wiel meerdere malen uitvinden.

Unit testen vind ik persoonlijk een onmisbaar onderdeel en ze worden ook steeds zwaarder omdat ik merk dat ik er tijd mee win. Je bent idd even bezig om unit test code toe te voegen, maar dat hoeft geen al te groot probleem te zijn aangezien je met een template al een heel eind komt. Verder worden mijn test directories door ANT ook automatisch afgescanned naar *TestSuite.java bestanden zodat ik alleen maar TestSuite bestanden hoef toe te voegen aan de test directories.

Die luxe heb ik helaas niet. Java is voor de meeste projecten hier niet geschikt, en autoconf / automake is rommel als je het mij vraagt : Het bugt en breekt weer anders met iedere release. Voorlopig plain makefiles, en als ik tijd over heb ga ik wel op zoek naar een fatsoenlijk buildsysteem.

Unit testen kun je op verschillende tijdstippen toevoegen. Als ik aan het prototypen ben wil ik geen blok aan mijn been in de vorm van unittests en maak ik alleen hele lichte tests als ik een stuk functionaliteit wil doorfluiten. Maar op het moment dat je van een prototype een serieus stuk software wilt maken, wordt iedere niet triviale methode grondig getests. Ik heb al zo`n enorme collectie met simpele foutjes verwijdert door unit testen, dat ik eigelijk geen software meer durf te schrijven zonder dit te testen.

Je leert ook om de fouten niet nogmaals te maken, vooral met valgrind merk ik dat sterk.

Verder hoeven unit testen ook geen onfunctioneel stuk code te zijn, want eigelijk zijn ze meer waard dan documenatie. In een unittest staat namelijk exact je contract beschreven: je ziet wat een object kan en niet kan. Unit testen zijn in dat opzicht uitvoerbare documentatie.

Gaat hier wat minder op.. Documentatie is vooral voor de eindgebruikers, een goed stuk code documenteert zichzelf.

Tot zover mijn verhaal over unit testen.. Ik wil dus graag weten wat jullie vinden van unit testen. Of jullie het gebruiken, in welke vorm en mate. Als je het niet gebruik, de argumenten waarom niet. En welke tools jullie hiervoor gebruiken.

Methoden :

- Stricte compiler flags. Warnings worden als error beschouwd.
- Testcases voor niet geteste code. Hergebruikte code wordt niet opnieuw opgenomen in
de testcases.
- Valgrind. Onmisbaar als je het mij vraagt als je C / C++ schrijft.

[edit]
Ik heb het hier alleen gehad over unit testen, maar uiteraard heb je ook acceptance en integration tests. Voeren jullie deze testen ook uit, en zo ja, hoe?[/quote]

Die tests zijn alleen zinvol bij grotere projecten in teamverband. Dat is hier zelfden het geval, dus een integration test doen we hier niet. Het uiteindelijk doortesten wordt ook door een 'vreemde' in het project gedaan, ivm de gouden regel 'Doe nooit een acceptance test op je eigen code'.

[igmar]

Donderwolk schreef op 28 mei 2004 @ 11:55:
Ik test meestal alleen de functies waarbij ik verwacht dat het mis zou kunnen gaan. Dus tijdens het programmeren zet ik daar dan meteen al een breakpoint neer.
In de debug mode zie ik dan vanzelf wel waar m'n brakke code het laat afweten om vervolgens meteen het probleem op te lossen.

Ik ben grotendeels afgestapt van debugger : Het is in 90% van de gevallen symptomenbestrijding. Ik gebruik alleen een debugger voor het bekijken van stacktraces indien de app core dumped. Verder doe ik alles met testcases en gewoon fprintf()'s.

[Verwijderd]

ik ben nu in het midden van een project waar we JSF hebben gebruikt, we wisten de risico's van het gebruiken van iets wat erg alfa was. Maar we gingen er mee aan de slag, we zagen af van Unit testen en wisten dat dit risico's met zich mee zou brengen. Nu op het latere stuk van het project merk je vooral dat we veel en veel te lang bezig zijn met debuggen, omdat het zoals aan de alfa software kan liggen als de core die niet geod getest is.

Ik heb me les wel geleerd, en doe wel aan unit testen nu.. en scheelt gigantische veel tijd en bij aanpassingen kun je nog altijd checken of alles werkt zoals het moet.

[Alarmnummer]

igmar schreef op 29 mei 2004 @ 13:03:
Ik compile standaard alles met -Wall -Werror -pedantic, en wijk daar maar in een paar situaties van af. Compiler warnings == bugs als je het mij vraagt. Verder is een goed design essentieel : Fouten onstaan en zijn moeilijk op te zoeken als je code nie modulair is opgebouwd (het is dan ook niet te testen). Verder is valgrind een essentieel onderdeel van het testen, en ik ben gaan merken dat ik steeds vaker foutloze code oplever.

Ik heb zo`n codemetrics tool waarmee ik zo nu en dan mijn code afstruin naar rare constructies en ongebruikte code.

Gaat hier wat minder op.. Documentatie is vooral voor de eindgebruikers, een goed stuk code documenteert zichzelf.

Het ligt heel aan het gene dat je maakt. Sommige dingen die hebben niet echt beschrijving nodig, maar andere zaken beschrij ik alles wat er verandert. Met de Prolog compiler heb ik instructies die uitgevoerd worden en ik beschrijf alles welke registers die ze aangepast moeten hebben. Dit is niet iets dat ik iedere keer zo maar even voor de geest kan halen, en in dat soort gevallen heb ik bijna voor iedere regel code ook wel een regel commentaar. Maar dat is niet vaak zo hoor Meestal is code gewoon te lezen als een goeie roman

- Stricte compiler flags. Warnings worden als error beschouwd.
- Testcases voor niet geteste code. Hergebruikte code wordt niet opnieuw opgenomen in
de testcases.

Mijn fouten zijn vaak semantische fouten en dat is niet iets dat de compiler kan detecteren. Ik heb het geluk dat ik met java kan werken, en veel minderin aanraking kom met pointer problematiek ed.

- Valgrind. Onmisbaar als je het mij vraagt als je C / C++ schrijft.

Dit is?

Die tests zijn alleen zinvol bij grotere projecten in teamverband. Dat is hier zelfden het geval, dus een integration test doen we hier niet. Het uiteindelijk doortesten wordt ook door een 'vreemde' in het project gedaan, ivm de gouden regel 'Doe nooit een acceptance test op je eigen code'.

Dat is idd een hele leuke regel En ken je verder het begrip monkeyproof? Overal op rammen en kijken wat er gebeurt. Kijken of je iets in een inconsistente toestand kan krijgen.

[MSalters]

igmar schreef op 29 mei 2004 @ 13:03:
- Valgrind. Onmisbaar als je het mij vraagt als je C / C++ schrijft.

Welnee. Het is uitsluitend in C nodig. In C++ is memory management een eitje, alloceren in ctor, vrijgeven in dtor, assignment als copy&swap implementeren - of nog beter, standaard classes gebruiken.

[igmar]

Alarmnummer schreef op 29 mei 2004 @ 13:41:
Ik heb zo`n codemetrics tool waarmee ik zo nu en dan mijn code afstruin naar rare constructies en ongebruikte code.

Zoiets heb ik ook, alleen vangt een flinke set flags het meeste wel af. Ik gebruik het daarom bijna nooit.

Het ligt heel aan het gene dat je maakt. Sommige dingen die hebben niet echt beschrijving nodig, maar andere zaken beschrij ik alles wat er verandert.

Ik documenteer in de code zelf alles waarvan ik weet dat a) iemand anders het niet meteen zal snappen, ook niet naar een paar keer doorlezen. b) Het volzit met vreemde constructies / code die echt niet anders kunnen. De recente interface naar de linux filter rules is z'n voorbeeld, dat snap ik echt niet meer als ik d'r een maand niet naar gekeken heb.

Met de Prolog compiler heb ik instructies die uitgevoerd worden en ik beschrijf alles welke registers die ze aangepast moeten hebben. Dit is niet iets dat ik iedere keer zo maar even voor de geest kan halen, en in dat soort gevallen heb ik bijna voor iedere regel code ook wel een regel commentaar. Maar dat is niet vaak zo hoor Meestal is code gewoon te lezen als een goeie roman

Zo hoort het ook. Alleen rare / ongebruikelijke dingen moet je documenteren.

Mijn fouten zijn vaak semantische fouten en dat is niet iets dat de compiler kan detecteren. Ik heb het geluk dat ik met java kan werken, en veel minderin aanraking kom met pointer problematiek ed.

Java is voor een hoop dingen ideaal. Voor dit project is het te onvoorspelbaar, en niet low-level genoeg. Pointers zijn een kwestie van ervaring en logisch nadenken. Verder is Java op Linux (veel) trager als Windows, wat ook een vrij grote tegen is.

Dit is?

Valgrind is een soort die je app draait op een virtuele processor, in staat is om bv alle toegang tot geheugenlocaties ed te controleren. Verder is d'r een plugin (skin) die bv ook profiling doet, een die alle geheugentoegang checked, parameters naar syscalls, aanroepen naar malloc / free. Zie valgrind

Dat is idd een hele leuke regel En ken je verder het begrip monkeyproof? Overal op rammen en kijken wat er gebeurt. Kijken of je iets in een inconsistente toestand kan krijgen.

Daar hebben we de wat minder kundige Windows gebruikers voor, een betere test is d'r niet De meeste zaken die ik maak zijn GUI loos, en draaien op de achtergrond, en daar is de monkeytest wat minder geschikt voor.

[igmar]

MSalters schreef op 29 mei 2004 @ 14:01:
Welnee. Het is uitsluitend in C nodig. In C++ is memory management een eitje, alloceren in ctor, vrijgeven in dtor, assignment als copy&swap implementeren - of nog beter, standaard classes gebruiken.

Een iets te simplistische kijk op het geheel als je het mij vraagt. Mensen die grotere projecten draaien (KDE, OpenOffice) denken d'r net zo over. C++ is geen garantie dat het memory management foutloos gaat.

[.oisyn]

igmar schreef op 29 mei 2004 @ 14:04:
[...]


Een iets te simplistische kijk op het geheel als je het mij vraagt. Mensen die grotere projecten draaien (KDE, OpenOffice) denken d'r net zo over. C++ is geen garantie dat het memory management foutloos gaat.

Java ook niet, en zo simplistisch is die kijk niet. Goed, bij C++ komt het vooral neer op ervaring, en nou hou ik niet zo van argeloos geheugen kopieren in elke copyconstructor, maar toch heb ik weinig problemen met memory management. Het is gewoon een kwestie van goed de verantwoordelijkheden tussen componenten verdelen; iemand die iets alloceert zou ook verantwoordelijk moeten zijn voor de opruiming. En verder heb je dingen als smartpointers en owners, het komt nog maar weinig voor dat ik een pointer laat rondslingeren en vergeet

[alienfruit]

Ik maak zelf zowel gebruik van unit testing, maar ik gebruik ook automated testing environment waar ik vooral applicatie tests uitvoer qua regressie, HTTP tests, GUI klik testen e.d. Door middel van verschillende scripts, werkt leuk.

[The - DDD]

Ik test een groot deel van mn private members via reflectie. Met reflectie kun je bij private member methods komen in Java en da's wel zo lekker als je een nogal belangrijke private member hebt.

Het heeft echter een nadeel, ga ik refactoren dan ga je met je unit tests redelijk snel de mist in. Daarom moet je het alleen doen met belangrijke private members. Overigens is het al snel een indicatie dat je moet refactoren als een deel van je private members al te zwaar getest moeten worden. Wie weet is het een los staand iets.

Ik wacht met smart op die metadata toevoegingen in Java, ik wil dan is kijken of je via dat mechanisme eenvoudig test code kan toevoegen.

[crisp]

ik test gewoon niet of nauwelijks eigenlijk; ik laat de klant de acceptatietest doen en meestal is het dan gewoon goed. Het gaat daarbij echter meestal wel om aanpassingen in bestaande software bij nijpende problemen waarbij geen tijd is om complete unit-tests uit te voeren. Ik heb situaties gehad waarbij ik binnen een uur een fix-programma heb moeten schrijven en over de productie-database heb laten draaien zonder voorafgaande tests om een probleem op te lossen
Nieuwe software heb ik meestal weinig mee te maken op implementaties na. Wat me dan meestal opvalt is dat ik toch vaak nog dingen tegen kom die duiden op duidelijke programmeerfouten, en ik vraag me dan vaak af waarom dat soort dingen in een testtraject dan niet naar boven zijn gekomen.

[EfBe]

Ik test voornl. dmv een testprogramma die functionaliteit test. Het zijn niet unittests omdat ik dan duizenden van die dingen nodig heb omdat mn code nogal complex en groot is.

[flowerp]

igmar schreef op 29 mei 2004 @ 13:13:
Ik ben grotendeels afgestapt van debugger : Het is in 90% van de gevallen symptomenbestrijding. Ik gebruik alleen een debugger voor het bekijken van stacktraces indien de app core dumped. Verder doe ik alles met testcases en gewoon fprintf()'s.

Ik werk juist bijna alleen maar (grafische) debugger based, en gebruik zelden of nooit cout's, printf's of println's enz. Mijn aanpak is dat ik als ik een stuk code schrijf ik regelmatig deze code run en dan met een debugger helemaal door heen step. Terwijl ik dat doe hou ik een set van geselecteerde variablen in de gaten. Bij complexe situaties hou ik het verloop van deze variablen bij op een blad papier.

Ik doe dit dus niet alleen wanneer er ergens een bug optreed, maar tijdens het schrijven van de code en redelijk systematisch. Veelal introduceer ik wat extra variablen in de code die tussen-resultaten opslaan zodat ik makkelijker over het verloop kan redeneren. Later verwijder ik deze weer en loop eventueel de code nog een maal door.

Het gebruikt van unit testen spreekt me ook zeker aan. Hoewel ik dit tot nu toe nog niet gebruikte staat het wel op mijn todo list van technologieen/methoden die ik nog wel leren gebruiken.

[Alarmnummer]

flowerp schreef op 30 mei 2004 @ 14:15:
[...]
Ik werk juist bijna alleen maar (grafische) debugger based, en gebruik zelden of nooit cout's, printf's of println's enz. Mijn aanpak is dat ik als ik een stuk code schrijf ik regelmatig deze code run en dan met een debugger helemaal door heen step. Terwijl ik dat doe hou ik een set van geselecteerde variablen in de gaten. Bij complexe situaties hou ik het verloop van deze variablen bij op een blad papier.

Gedsie een debugger Het nadeel aan jouw aanpak is dat je na afloop de testcode kwijt raakt. Dus als je later iets gaat aanpassen (met het risico dat je een fout introduceert) moet je alle bestaande code misschien afzoeken en opnieuw die tests schrijven. Met unit testen hou je die testen dus in je systeem en is dus on the long run veel goedkoper.

[flowerp]

igmar schreef op 29 mei 2004 @ 14:01:

[Maar dat is niet vaak zo hoor Meestal is code gewoon te lezen als een goeie roman]
Zo hoort het ook. Alleen rare / ongebruikelijke dingen moet je documenteren.

Het zogenaamde literair programmeren zoals Donald E. Knuth voorstaat? Opzich is dat mooi, maar persoonlijk ben ik het er fundamenteel mee oneens als er dan niet ook nog normaal commentaar bijstaat. De kunst is juist om in je commentaar een abstractie voor een blok code te vangen die hoger staat dan de code zelf. Dat dit niet overal hoeft staat vast, maar ik ken het type oude C programmeurs als igmar wel ( ), die zeggen dat je alleen rare dingen moet commenten en dat de rest van de comments 'sparse' zijn. Als je dan naar hun sourcecode kijkt staan er gewoon -geen- comments, niet weinig, maar gewoon geen.

Niet geheel toevallig zijn dit vaak de zelfde types die atoi een goede naam vinden en lachen om een naam als convertArrayStringToInteger oid. Ook zijn dit dezelfde types die atoi graag in 2 niet te volgen regels op schrijven, ipv iets dat makkelijker te doorlezen is maar meerdere regels beslaat. (stond in 1998 ofzo een leuk artikel over in C'T, ging toen inderdaad over de atoi implementatie).

Voor vele low-level programmeurs is goed commenten gewoon te moeilijk. Ze zeggen dat ze het niet leuk vinden, of onzin vinden, maar vaak kunnen ze het gewoon niet. Het is vaak ook een kwestie van een soort egoisme; "Ik snap deze code, en als andere het niet meteen snappen zijn ze dom". Dat het code reviews vertraagt ligt dus niet aan hun, maar aan de anderen die niet genoeg niveau zouden hebben. Natuurlijk zeg ik niet dat igmar dit denkt

[flowerp]

Alarmnummer schreef op 30 mei 2004 @ 14:31:
[...]
Gedsie een debugger

Ik heb er al meerdere malen erg veel profijt van gehad. Op mijn werk zit een andere programmeur die zeker niet dom is. In zijn code zat een bug waar ie maar niet achter kwam waar ie zat. Zelf gebruikt ie alleen println's als debug mechanisme en test functies. Ik loop er een keer met een debugger door waar ik stap voor stap alles in de gaten hou, en binnen vijf minuten heb ik de fout: bij een insert in een map waren perongeluk een key en een value omgedraaid. Door -heel erg ongelukkig- gekozen variable namen kwam dit niet eerder aan het licht. Met de debugger kon ik tevens de map grafisch unfolden en in 1 oogopslag zien dat er wat fout ging.

Het nadeel aan jouw aanpak is dat je na afloop de testcode kwijt raakt.

Min of meer waar ja, daarom wil ik ook zeker naar unit testen gaan kijken. Zowieso vind ik dat we op ons werk veels te weinig testen. Vaak gaat code live waar we twee uur geleden nog aan zaten te werken.

Dus als je later iets gaat aanpassen (met het risico dat je een fout introduceert) moet je alle bestaande code misschien afzoeken en opnieuw die tests schrijven.

Niet perse, je kunt de test code ook gewoon weg commenten of als je met C/C++ werkte tussen #ifdefine __DEBUG__ oid zetten. Maar het blijft natuurlijk adhoc ipv systematisch...

[FireWood]

Ik ben de debugger van Questa
Het leuke is dat hij een prog had wat hij aan verschillende personen al had gestuurt om te ontbuggen. Toen ik het kreeg had ik in de eerst minuut een fout of 10 ontdekt Oftewel stuur het naar iemand die gewoon alles kan slopen

[EfBe]

flowerp schreef op 30 mei 2004 @ 14:15:
Ik werk juist bijna alleen maar (grafische) debugger based, en gebruik zelden of nooit cout's, printf's of println's enz. Mijn aanpak is dat ik als ik een stuk code schrijf ik regelmatig deze code run en dan met een debugger helemaal door heen step. Terwijl ik dat doe hou ik een set van geselecteerde variablen in de gaten. Bij complexe situaties hou ik het verloop van deze variablen bij op een blad papier.

Debuggen != testen. Testen is semantics testen. Debuggen is het vinden van fouten, dus wanneer je al hebt geconstateerd dat je programma een fout bevat.

Laat me raden, jij bent zeker ook een voorstander van Edit & Continue?

[Verwijderd]

ik lees hier dat er mensen geen unit tests willen gebruiken omdat ze hun code dan moeten aanpassen. Dat snap ik toch wel neit zo goed...
Volgens mij test je overal waar je kan testen. Bij ons enkel de business layer op sessionlayer (EJB) niveau en dan op de acherliggende businesscomponent klassen (met de business logic). Verder werken we aan de implementatie van httpunit.
Niets van onze code wordt beinvloed door onze testen, testen testen, ze bepalen de code zelf niet, enkel de resultaten van de calls.

Verder hebben we constant Cruisecontrol aan het werk. Dat is hier nog niet vernoemd, maar ons project is dermate groot dat sommige wijzigingen op andere modules impact hebben en niet iedere developper denkt eraan om ALLE tests te draaien (trage development server + véél tests).

Cruisecontrol doet de update van clearcase (version control), en als er updates zijn kijkt hij wie dingen ingecheckt heeft, hij lanceert een build, deployed en draait alle testen op een ververst DB schema (geen invloed van door tests gewijzigde gegevens) en stuurt de resultaten naar de mensen die check-ins gedaan hebben. Op die manier weet je of er iets foutloopt of je wijziging goed was. Het is echt wel een efficiënt systeem dat tot onze aller tevredenheid reeds enkele weken (ok, nog niet zoveel ervaring ) draait. Zijn er nog mensen die zo werken?

Verder rust op elke developper de verplichting om een bug te testen met een falende unit test, dan een oplossing te verzorgen en de test te draaien die dan uiteraard moet slagen. Op die manier wordt onze hoeveelheid tests gestaag uitgebreid zonder al te veel tijdverlies. Je bent ook zeker van je wijziging.

[flowerp]

EfBe schreef op 30 mei 2004 @ 15:50:
Debuggen != testen
Testen is semantics testen. Debuggen is het vinden van fouten, dus wanneer je al hebt geconstateerd dat je programma een fout bevat.

Leuk die definities, maar precies waarom is het gebruik van een debugger om variablen te bekijken evil? Als cout << "userKey: " << userKey << " serverSlot: " serverSlot << endl; enz enz... wel mag, waarom mag ik dan niet via mijn debugger kijken wat die variablen als waarden hebben? Je zou kunnen zeggen dat de debugger voor mij, in dit geval, de universele cout is mbt het weergeven van variabelen.

Testen is een zeer breed begrip. Als ik snel wil testen of na een loop variable X de gewenste waarde heeft, waarom zou ik dan niet na de loop een breakpoint zetten om te controleren of dat klopt? -Mag- dat van jou alleen dmv een cout?

Als ik wil testen of mijn datastructuur correct is opgebouwt in het geheugen, waarom zou ik deze dan niet in de debugger inspecteren?

Ik denk, beste Efbe, dat jij je te zeer vastpint op de naam die het beestje heeft: Debugger roept bij jou (mischien) een verkeerde associatie op. Voor mij is een debugger niet alleen een middel om te debuggen, maar ook een tool om de state van mijn code op een bepaald soort manier te visualiseren, om mezelf in inside-look te geven. Een semantische test kan daar mee samen vallen, of kan dat niet. Dat hangt van de code in kwestie af.

Testen gaat in verschillende fasen, van de schets op papier van een algortime, via een compile (maakte ik geen syntax fouten), via een -snelle- test-run, via een -snelle- inspectie van de state, via unit testen, via code reviews, via acceptence & QA tests, tot en met de praktijk test.

Mischien ben jij, Efbe, zoiemand die van die dingen op zijn CV schrijft als "nauwkeurigheid: ik maak minder dan 0.01 fouten per 1000 regels" oid, maar in de praktijk gebruikt elke programmeur die ik ken een vorm van "cout" testen. Heck, in veel opensource code die ik lees staan de cout's of printf's nog gecomment. Ipv cout bekijk ik de waardes via een debugger. Ik jou ogen ben ik nu een slechte ontwikkelaar?

Laat me raden, jij bent zeker ook een voorstander van Edit & Continue?

Nee, nooit gebruikt en ben er ook geen voorstander van. Net zomin als ik er een voorstander van ben om tijdens debuggen waarden van variablen te veranderen.
Jij wel?

Maar laat mij ook eens raden, jij bent zeker een voorstander van formele correctheids bewijzen voor je gehele code? De pre-inspectie voer je uit over iedere regel code die je schrijft?

[whoami]

flowerp schreef op 30 mei 2004 @ 16:27:
[...]
Testen is een zeer breed begrip. Als ik snel wil testen of na een loop variable X de gewenste waarde heeft, waarom zou ik dan niet na de loop een breakpoint zetten om te controleren of dat klopt? -Mag- dat van jou alleen dmv een cout?

Als ik wil testen of mijn datastructuur correct is opgebouwt in het geheugen, waarom zou ik deze dan niet in de debugger inspecteren?

Ik denk, beste Efbe, dat jij je te zeer vastpint op de naam die het beestje heeft: Debugger roept bij jou (mischien) een verkeerde associatie op. Voor mij is een debugger niet alleen een middel om te debuggen, maar ook een tool om de state van mijn code op een bepaald soort manier te visualiseren, om mezelf in inside-look te geven. Een semantische test kan daar mee samen vallen, of kan dat niet. Dat hangt van de code in kwestie af.

Testen is niet hetzelfde als debuggen.
Met testen bepaal je of je code / module / method een fout bevat, en met debuggen kan je die fout in je code gaan opsporen.

Om te unit testen schrijf je 'testcode'. Code die je schrijft waarin je je methods aanroept, en daar dmv Asserts oid al aangeeft of de output correct is of niet. Met een testprogramma als NUnit kan je dan zien welke tests er goed en fout verlopen zijn.

Ipv cout bekijk ik de waardes via een debugger. Ik jou ogen ben ik nu een slechte ontwikkelaar?

Dat heeft helemaal niks met een goeie of slechte ontwikkelaar te maken. Iedereen bekijkt die variabelen zoals hij het zelf wil. Soms kan je het doen via watches, soms via console - outputs.
Ik vind het wel slordig om die statements in je code te laten staan.

[ Voor 9% gewijzigd door whoami op 30-05-2004 16:50 ]

[flowerp]

whoami schreef op 30 mei 2004 @ 16:48:
[...]

Testen is niet hetzelfde als debuggen.

Dat klopt Maar je kunt een debugger wel gebruiken voor een snelle test. Net zoals je cout voor een snelle test gebruikt. Klopen de waardes/gedrag niet? Dan ga je echt debuggen.

Dat heeft helemaal niks met een goeie of slechte ontwikkelaar te maken. Iedereen bekijkt die variabelen zoals hij het zelf wil. Soms kan je het doen via watches, soms via console - outputs.
Ik vind het wel slordig om die statements in je code te laten staan.

Nou, terwijl ik aan het ontwikkelen ben laat ik wel eens wat statements staan, maar volgens mij doet iedereen dat wel. Ik zag dat bij mede-studenten, ik zie het bij collega's en ik zie het in opensource projecten. Bij code cleanups gaan al zulksoort dingen eruit. Alarmnummer merkte terrecht op dat je dan je test-code kwijt ben, en daar ben ik het zeer mee eens.

Het enige wat ik wel eens laat staan zijn echte test-functies. Soms copy-paste ik ze naar aparte bestanden. En soms zet ik deze (complete functies) tussen #ifdefine's als het C of C++ is of comment ik ze uit. Een beetje informeel is dit dus al het begin van unit tests. Op dit punt kan ik het dus absoluut nog beter doen.

[whoami]

flowerp schreef op 30 mei 2004 @ 18:24:
[...]

Bij code cleanups gaan al zulksoort dingen eruit. Alarmnummer merkte terrecht op dat je dan je test-code kwijt ben, en daar ben ik het zeer mee eens.

Dat is het voordeel van 'echte' unittests.
Je testcode zit in een apart project, en die ben je dus niet kwijt.

bv:

code:

[TestFixture]
    public class RectangleTest
    {
          [Test]
         public void TestArea()
         {
          Rectangle r = new Rectangle(4, 4);
            
          Assert.IsTrue (r.GetOppervlakte() == 14;
         }
    }
}

[ Voor 22% gewijzigd door whoami op 30-05-2004 20:48 ]

[igmar]

.oisyn schreef op 29 mei 2004 @ 16:50:
Java ook niet, en zo simplistisch is die kijk niet.

De constructor / destructor regel gaat gewoonweg niet altijd op, en is geen argument om tools zoals valgrind niet te gebruiken. Een kwestie van ervaring is het zeker, en ondanks het feit dat ik nog zelden leaks heb blijf ik de checks doen.

Goed, bij C++ komt het vooral neer op ervaring, en nou hou ik niet zo van argeloos geheugen kopieren in elke copyconstructor, maar toch heb ik weinig problemen met memory management. Het is gewoon een kwestie van goed de verantwoordelijkheden tussen componenten verdelen; iemand die iets alloceert zou ook verantwoordelijk moeten zijn voor de opruiming. En verder heb je dingen als smartpointers en owners, het komt nog maar weinig voor dat ik een pointer laat rondslingeren en vergeet

Het verdelen is ook een kwestie van ervaring, als je het je eenmaal eigen hebt gemaakt doe je niet anders. Da's tenminste mijn ervaring

[igmar]

flowerp schreef op 30 mei 2004 @ 14:15:
Ik werk juist bijna alleen maar (grafische) debugger based, en gebruik zelden of nooit cout's, printf's of println's enz. Mijn aanpak is dat ik als ik een stuk code schrijf ik regelmatig deze code run en dan met een debugger helemaal door heen step. Terwijl ik dat doe hou ik een set van geselecteerde variablen in de gaten. Bij complexe situaties hou ik het verloop van deze variablen bij op een blad papier.

Veels te tijdrovend als je het mij vraagt. Op papier zetten doe ik zelden : Het wijst meestal op een slecht ontwerp. Aan m'n initieele ontwerp moet ik naar mijn idee voldoende aan hebben.

Ik doe dit dus niet alleen wanneer er ergens een bug optreed, maar tijdens het schrijven van de code en redelijk systematisch. Veelal introduceer ik wat extra variablen in de code die tussen-resultaten opslaan zodat ik makkelijker over het verloop kan redeneren. Later verwijder ik deze weer en loop eventueel de code nog een maal door.

Da's niet mijn favo aanpak als ik eerlijk moet zijn

[igmar]

flowerp schreef op 30 mei 2004 @ 15:18:
Het zogenaamde literair programmeren zoals Donald E. Knuth voorstaat? Opzich is dat mooi, maar persoonlijk ben ik het er fundamenteel mee oneens als er dan niet ook nog normaal commentaar bijstaat.

Geen idee wat de formele benaming is, maar ik ben het er wel mee eens. Commentaar moet ergens toe bijdragen, en teveel is zeker niet goed. Te weinig is ook niet goed. Alla de kernel code dus

De kunst is juist om in je commentaar een abstractie voor een blok code te vangen die hoger staat dan de code zelf. Dat dit niet overal hoeft staat vast, maar ik ken het type oude C programmeurs als igmar wel ( ), die zeggen dat je alleen rare dingen moet commenten en dat de rest van de comments 'sparse' zijn. Als je dan naar hun sourcecode kijkt staan er gewoon -geen- comments, niet weinig, maar gewoon geen.

Functies moeten deelproblemen oplossen, en een zodanige naamgeving hebben dat je aan de functienaam eigenlijk al kan afleiden wat het doet. Als je commentaaar nodig hebt om ook maar enigszins duidelijk te maken wat het doet is d'r iets mis met je naamgeving.

Niet geheel toevallig zijn dit vaak de zelfde types die atoi een goede naam vinden en lachen om een naam als convertArrayStringToInteger oid.

Vreselijk, Hongaarse notatie. Onnatuurlijke naamgeving, en de prefixes dragen ook nergens toe bij. Afgezien van het feit dat atoi() een functie is die je zowiezo nooit moet gebruiken is de naamgeving voor verbetering vatbaar. ConvertStringToInteger() is echter de meest vreselijke naamgeving die ik kan bedenken.

Ook zijn dit dezelfde types die atoi graag in 2 niet te volgen regels op schrijven, ipv iets dat makkelijker te doorlezen is maar meerdere regels beslaat. (stond in 1998 ofzo een leuk artikel over in C'T, ging toen inderdaad over de atoi implementatie).

Ik kan me niet voorstellen dat atoi() meerdere regels nodig heeft. met strtol() kan ik me dat wel voorstellen, maar de code zo cryptisch mogelijk opschrijven is een slechte zaak. atoi() is vrij simpel : Je stopt d'r wat in, en je krijgt d'r wat uit. Controleren of het goed is gegaan kan niet, dus errorchecking is ook niet aan de orde.

Voor vele low-level programmeurs is goed commenten gewoon te moeilijk. Ze zeggen dat ze het niet leuk vinden, of onzin vinden, maar vaak kunnen ze het gewoon niet. Het is vaak ook een kwestie van een soort egoisme; "Ik snap deze code, en als andere het niet meteen snappen zijn ze dom". Dat het code reviews vertraagt ligt dus niet aan hun, maar aan de anderen die niet genoeg niveau zouden hebben. Natuurlijk zeg ik niet dat igmar dit denkt

Commentaar moet nuttig bijdragen aan de leesbaarheid en begrijpbaarheid van de code. Als dat het niet doet is het commentaar overbodig. Zoiets als

code:

/* Dit loopje gaat van 0 tm 19 */
for (i = 0; i < 20; i++) {
   ....
}

is totaal overbodig : Dat de loop van 0 tm 19 telt is meteen afleidbaar. Een stuk code die zwarte magie uithaalt met void * behoeft bv vaak wel commentaar, aangezien vaak het waarom van de code niet meteen duidelijk is.

[igmar]

flowerp schreef op 30 mei 2004 @ 16:27:
Heck, in veel opensource code die ik lees staan de cout's of printf's nog gecomment. Ipv cout bekijk ik de waardes via een debugger. Ik jou ogen ben ik nu een slechte ontwikkelaar?

Het 'probleem' wat ik met debuggers heb is dat ik van mening ben dat veel programmeurs dan symptomen bestrijden : Men lost probleem X op in functie Y, ipv in functie Z waar het eigenlijke probleem zit, of ipv een gedeelte van de implementatie (of ontwerp) te veranderen. Hoe men debugged is verder niet belangrijk : Ik doe het met printf()'s, de ander met een debugger. Een kwestie van smaak als je het mij vraagt.

[whoami]

igmar: kon je de edit knop niet vinden ofzo?

[flowerp]

whoami schreef op 30 mei 2004 @ 20:47:
[...]

Dat is het voordeel van 'echte' unittests.
Je testcode zit in een apart project, en die ben je dus niet kwijt.

bv:

code:

[TestFixture]
    public class RectangleTest
    {
          [Test]
         public void TestArea()
         {
          Rectangle r = new Rectangle(4, 4);
            
          Assert.IsTrue (r.GetOppervlakte() == 14;
         }
    }
}

Het lijkt me echt een goede methode. Ik denk dat ik hier zeer binnenkort mee ga beginnen. :-)

Toch zou ik niet te veel alleen op deze testen vertrouwen, het blijft natuurlijk maar een gedeelte van je input domain wat je test. In jouw voorbeeld test je (4,4), maar test je ook (3,3), en (65536, 256) ? Er blijft altijd een kans dat het net fout gaat bij een geval die jij niet test. En hoe bereken je de output om te controleren? Niet doordezelfde functie die je nu test natuurlijk. Met een andere, reeds bestaande functie? Maar waarom schrijf je dan de nieuwe functie?

Maar goed, je test natuurlijk een goede representatie van je invoer.

Andere dingen die je (lijkt me) niet met unit testen covert is dingen die je gewoon vergeet en niet van te voren voorziet. Ik had bv niet zo lang geleden een tabel die diep in de code gegenereert wordt en waarbij later in wat hogere code regionen met elke rij een extra data item gelinked wordt. Recent bedachten we dat deze tabel gesorteerd moest worden, en dat deden we vlak na de plek waar deze aangemaakt wordt. Helaas was ik helemaal die extra items vergeten.

Een unit test had me hier niet op gewezen, omdat dit iets was wat ik gewoon vergeten was. Natuurlijk had ik een unit test kunnen hebben om deze relatie te testen, maar op het moment dat deze dan geschreven had moeten worden was er nog helemaal geen sprake van dat er ooit een mis-match zou -kunnen- bestaan. Als dat toen voorzien was had de interface en code anders opgezet geworden. (maar zovaak in developpen, -als- je alles van tevoren weet...)

[Alarmnummer]

flowerp schreef op 30 mei 2004 @ 23:15:
[...]


Toch zou ik niet te veel alleen op deze testen vertrouwen, het blijft natuurlijk maar een gedeelte van je input domain wat je test. In jouw voorbeeld test je (4,4), maar test je ook (3,3), en (65536, 256) ? Er blijft altijd een kans dat het net fout gaat bij een geval die jij niet test

De kunst van het testen is om zoveel mogelijk bugs in zo weinig mogelijk tijd eruit te halen. Je kunt dus nooit alle combinaties proberen en daarom moet je je tevreden stellen met een beperkt aantal. Je kunt dit aantal op 2 manieren samenstellen, via blackbox en whitebox. Als je uitgaat van een blackbox dan kun j e voor de hand liggende combinaties proberen en met een whitebox heb je inzicht in de code en kan je daar je test ook op maken:

code:

int bepaalLoon(int sofirnr){
    if(sofinr == alarmnummers_sofinr)
           return 10000000....000000;
    return 1000;
}

Deze methode had je met een blackbox dus nooit goed kunnen afvangen, maar met een whitebox weer je dat er dus 1 bepaalde uitzondering is. Meestal is dit wel iets dat in de documentatie van de functie beschreven moet staan.

. En hoe bereken je de output om te controleren? Niet doordezelfde functie die je nu test natuurlijk. Met een andere, reeds bestaande functie? Maar waarom schrijf je dan de nieuwe functie?

Dat is afhankelijk van de situatie. Sommige dingen kan ik met de hand bepalen, simpel voorbeeld: ik weet dat de size van een stack na afloop van een pop 1 kleiner moet zijn dan hij eerst was (tenzij de stack al leeg was). Maar andere dingen zoals compressie van een plaatje die kan je niet met de hand meer bepalen.

Andere dingen die je (lijkt me) niet met unit testen covert is dingen die je gewoon vergeet en niet van te voren voorziet. Ik had bv niet zo lang geleden een tabel die diep in de code gegenereert wordt en waarbij later in wat hogere code regionen met elke rij een extra data item gelinked wordt. Recent bedachten we dat deze tabel gesorteerd moest worden, en dat deden we vlak na de plek waar deze aangemaakt wordt. Helaas was ik helemaal die extra items vergeten.

Een unit test had me hier niet op gewezen, omdat dit iets was wat ik gewoon vergeten was. Natuurlijk had ik een unit test kunnen hebben om deze relatie te testen, maar op het moment dat deze dan geschreven had moeten worden was er nog helemaal geen sprake van dat er ooit een mis-match zou -kunnen- bestaan. Als dat toen voorzien was had de interface en code anders opgezet geworden. (maar zovaak in developpen, -als- je alles van tevoren weet...)

Je moet unit testen niet zien als 'de' test voor je systeem. Het wil niet zeggen dat je met unit testen alle bugs uit je systeem haalt. Maar je haalt er wel een hele zooi mee uit je systeem. In principe zou je alle bugs er wel uit kunnen halen met testen, maar dan zal testen geen tijd winst opleveren. En tenslotte draait het tegenwoordig allemaal om tijd (en tijd is geld).

[flowerp]

igmar schreef op 30 mei 2004 @ 22:11:

Commentaar moet nuttig bijdragen aan de leesbaarheid en begrijpbaarheid van de code. Als dat het niet doet is het commentaar overbodig. Zoiets als

code:

/* Dit loopje gaat van 0 tm 19 */
for (i = 0; i < 20; i++) {
   ....
}

-DAT- is nu juist een schoolvoorbeeld van onzin commentaar ja. Dat is net zoiets als

code:

int a = 4; // a wordt 4

Als ik zoiets zie tijdens een code review van (jongere) programmeurs waar ik een beetje de leiding over heb dan gaat er meteen een rode streep door met als commentaar van mij: "Ga er vanuit dat de lezer C++ kent." (in het geval van C++).

Zoals ik boven al stelde, commentaar moet op een hoger abstractie niveau staan. Als je code in een aparte functie kan, mooi, dan comment je de functie en geeft de naam v/d functie het doel van de code. Goed gekozen variable namen zorgen ook al voor een hoog zelfbeschrijvings gehalte.

Wat ik bv bedoel is zoiets als:

C++:

if (modelTransition == true) {
  // -user- requested model transition, so we need to restore the original model 
  // since the transition needs to have flowX and flowY data that is present only
  // in the original model. Transitions never re-execute
  // any model creating command themselves. For all other operations, this original 
 //model is not needed and thus not restored.
  modelCreater* ModelCreater = new ModelCreater();
  modelCreater->setState(this);
  stateTable.resync(modelCreater);
  // ...
}

Dit is dus onderdeel van code die een state restore doet. Je ziet aan de code zelf wel dat een transitie een nieuw model nodig heeft, maar waarom? De comments zeggen dat dus. Sommige programmeurs vinden dit soort commentaar erg overdreven; je kunt namelijk ook in de code voor een transitie kijken waarom er een origineel model nodig is. Ik zelf vind dit echter veel makkelijker omdat ik zo een stuk code in 1 maal door kan lezen zonder telkens naar andere files te springen, waarin ik ook weer naar weer andere moet gaan enz...

[EfBe]

flowerp schreef op 30 mei 2004 @ 16:27:
Leuk die definities, maar precies waarom is het gebruik van een debugger om variablen te bekijken evil? Als cout << "userKey: " << userKey << " serverSlot: " serverSlot << endl; enz enz... wel mag, waarom mag ik dan niet via mijn debugger kijken wat die variablen als waarden hebben? Je zou kunnen zeggen dat de debugger voor mij, in dit geval, de universele cout is mbt het weergeven van variabelen.

Omdat het runnen van een testprogramma je precies de waarden geeft waar je naar op zoek bent (of dus niet en dan heb je een bug) maar in de debugger het vele malen langer duurt voordat je die waarden hebt. Een assert is echt veel sneller dan door een lap code steppen en dan een local's value checken.

Testen is een zeer breed begrip. Als ik snel wil testen of na een loop variable X de gewenste waarde heeft, waarom zou ik dan niet na de loop een breakpoint zetten om te controleren of dat klopt? -Mag- dat van jou alleen dmv een cout?

Waarom plaats je geen assert? Die worden weggecompileerd in release builds en in debug builds geven ze je precies aan waar je een fout hebt. Kost je geen enkele moeite, en je bespaart echt heel veel tijd.

Als ik wil testen of mijn datastructuur correct is opgebouwt in het geheugen, waarom zou ik deze dan niet in de debugger inspecteren?

Ten eerste lijkt me dat onbegonnen werk bij een wat ingewikkelde datastructuur en ten tweede is het me onduidelijk waarom je niet middels programmatuur test, immers een paar regels code maken GEEN fouten, echter jij die naar een locals windowtje staart maakt GEHEID een fout af en toe, los van het feit dat het mega-veel tijd kost.

Ik denk, beste Efbe, dat jij je te zeer vastpint op de naam die het beestje heeft: Debugger roept bij jou (mischien) een verkeerde associatie op. Voor mij is een debugger niet alleen een middel om te debuggen, maar ook een tool om de state van mijn code op een bepaald soort manier te visualiseren, om mezelf in inside-look te geven. Een semantische test kan daar mee samen vallen, of kan dat niet. Dat hangt van de code in kwestie af.

Een debugger geeft je inderdaad die insights, echter is het dermate tijdverslindend en voor het geval van visuele check ook nog eens error-gevoelig (want jij bent een mens en die maken fouten) dat voor het testen of iets correct is je veel beter asserts kunt gebruiken.

Testen gaat in verschillende fasen, van de schets op papier van een algortime, via een compile (maakte ik geen syntax fouten), via een -snelle- test-run, via een -snelle- inspectie van de state, via unit testen, via code reviews, via acceptence & QA tests, tot en met de praktijk test.

snelle inspectie van de state dmv een debugger is een farce. Als ik mn 3MB grote codebase met een debugger moet doorsteppen ben ik een dag bezig zeg.

Mischien ben jij, Efbe, zoiemand die van die dingen op zijn CV schrijft als "nauwkeurigheid: ik maak minder dan 0.01 fouten per 1000 regels" oid, maar in de praktijk gebruikt elke programmeur die ik ken een vorm van "cout" testen.

Ik ben opgegroeid met de gnu commandline debugger op een VAX, ik weet echt wel hoe je programma's moet testen en debuggen en dat er veel tools zijn die veel sneller testen of pre en post condities (want dat ben je toch aan het testen) kloppen dan een debugger. Sterker, tijdens veel debug sessies start ik echt geen debugger op. En nee ik gebruik geen printf's meer.

Overigens vind ik je vrij zelfingenomen overkomen, terwijl je de ballen verstand hebt van de tools die tot je beschikking staan.

Heck, in veel opensource code die ik lees staan de cout's of printf's nog gecomment. Ipv cout bekijk ik de waardes via een debugger. Ik jou ogen ben ik nu een slechte ontwikkelaar?

Laat ik 'slecht' niet in de mond nemen, maar voor een project ben je zeker niet goed, daar je veel tijd opvreet met het visueel (en dus incorrect per definitie) checken van state dat je ook middels asserts kunt testen.

Nee, nooit gebruikt en ben er ook geen voorstander van. Net zomin als ik er een voorstander van ben om tijdens debuggen waarden van variablen te veranderen.
Jij wel?

Nee niet echt. http://weblogs.asp.net/fbouma/archive/2003/08/01/22211.aspx

Maar laat mij ook eens raden, jij bent zeker een voorstander van formele correctheids bewijzen voor je gehele code? De pre-inspectie voer je uit over iedere regel code die je schrijft?

Ze zijn zeker nuttiger dan veel tijd verprutsen in een debugger om visueel de state van het programma te gaan bekijken.

[EfBe]

igmar schreef op 30 mei 2004 @ 22:11:
Vreselijk, Hongaarse notatie. Onnatuurlijke naamgeving, en de prefixes dragen ook nergens toe bij. Afgezien van het feit dat atoi() een functie is die je zowiezo nooit moet gebruiken is de naamgeving voor verbetering vatbaar. ConvertStringToInteger() is echter de meest vreselijke naamgeving die ik kan bedenken.

Het is een zeer juiste benaming, en vertelt precies wat het doet, een string naar int converteren, iets dat je zelf juist wilt propageren. Overigens is dat geen hungarian, hungarian is iets als:

int m_iFoo;
bool m_bFlag;

Ik kan me niet voorstellen dat atoi() meerdere regels nodig heeft. met strtol() kan ik me dat wel voorstellen, maar de code zo cryptisch mogelijk opschrijven is een slechte zaak. atoi() is vrij simpel : Je stopt d'r wat in, en je krijgt d'r wat uit. Controleren of het goed is gegaan kan niet, dus errorchecking is ook niet aan de orde.

Errorchecking is niet nodig omdat de functie geacht wordt juist te werken, niet omdat het niet kan. Zo bouw je correcte software: je test een functie of deze doet wat de semantische definitie zegt dat deze moet doen, als dat klopt is de functie goed en kun je in je eigen code daar op voortborduren. Dat is ook de basis van unittests (en veel mensen gebruiken unittests al jaren ookal weten ze dat niet): je test de semantics van een complete interface. Je kunt ongestoord met de code achter die interface rommelen totdat je denkt dat je klaar bent, als die unittests maar kloppen daarna, zodat de semantics van de interface niet zijn gewijzigd.

[EfBe]

flowerp schreef op 31 mei 2004 @ 00:13:

code:

int a = 4; // a wordt 4

Als ik zoiets zie tijdens een code review van (jongere) programmeurs waar ik een beetje de leiding over heb dan gaat er meteen een rode streep door met als commentaar van mij: "Ga er vanuit dat de lezer C++ kent." (in het geval van C++).

De syntax van C++ is dermate uitgebreid dat je er niet vanuit mag gaan dat iedere lezer C++ moet kennen, daar het gros van de C++ ontwikkelaars niet voor 100% de syntax kent. (maar int i=4; is wel erg suf)

C++:

if (modelTransition == true) {
  // [...]
  modelCreater* ModelCreater = new ModelCreater();
  modelCreater->setState(this);
  stateTable.resync(modelCreater);
  // ...
}

Het is wellicht ook handig af en toe het Engelse woordenboek erbij te pakken (CreatOr )

Is het ook niet beter voor methods CaMelCasing te gebruiken?

Dit is dus onderdeel van code die een state restore doet. Je ziet aan de code zelf wel dat een transitie een nieuw model nodig heeft, maar waarom? De comments zeggen dat dus. Sommige programmeurs vinden dit soort commentaar erg overdreven; je kunt namelijk ook in de code voor een transitie kijken waarom er een origineel model nodig is. Ik zelf vind dit echter veel makkelijker omdat ik zo een stuk code in 1 maal door kan lezen zonder telkens naar andere files te springen, waarin ik ook weer naar weer andere moet gaan enz...

Klopt, het is alleen de vraag of je ontwerpbeslissingen, want daar heb je het hier over, alleen in de code moet opnemen, omdat je ze nooit en te nimmer meer terugvindt wanneer je ergens anders iets moet wijzigen wat afhangt van een ontwerpbeslissing in een andere functie en die beslissing is alleen in de code verwoord.

[Verwijderd]

EfBe schreef op 31 mei 2004 @ 10:07:
[...]

De syntax van C++ is dermate uitgebreid dat je er niet vanuit mag gaan dat iedere lezer C++ moet kennen, daar het gros van de C++ ontwikkelaars niet voor 100% de syntax kent. (maar int i=4; is wel erg suf)

[...]

Je hebt gelijk, maar de syntax is altijd op te zoeken, met de juiste naamgeving van methoden en goede comments over de toepassing ervan hoef je de syntax niet te kennen om de code te kunnen lezen.

[MaxxRide]

Ik ben het wel eens met de stelling dat je alleen abstract commentaar in je code moet plaatsen. Het beschrijven van 1 enkel statement heeft imo weining nut, tenzij dit een zeer bijzonder geval is het statement.

Wat je zegt over design beslissingen ben ik het niet mee eens. Vaak zijn de beslissingen in het design niet direct gerelateerd aan de stuk code in het design. Het design wordt later vertaald naar een stuk code. Wat wel mooi is om in de code een verwijzing op te nemen naar de beslissingen genomen in het design. (Zo zou je dus ook een verwijzing op kunnen nemen naar een passage in je design waar b.v. ook in staat wat de gevolgen voor andere delen in het systeem zijn).

[EfBe]

Verwijderd schreef op 31 mei 2004 @ 10:15:
Je hebt gelijk, maar de syntax is altijd op te zoeken, met de juiste naamgeving van methoden en goede comments over de toepassing ervan hoef je de syntax niet te kennen om de code te kunnen lezen.

Nou, de syntax is wel op te zoeken, maar begrijpen daarvan is essentieel voor het begrijpen van de code. Waar trek je de lijn is inderdaad lastig, maar aannemen dat iedereen C++ kent tot in de puntjes lijkt me wat al te voorbarig en levert niet een beter begrip bij de lezer op, in tegendeel, die gaat dingen aannemen als "het zal wel zo zijn" terwijl dat wellicht niet zo is.

Altijd leuk voorbeeld zijn bv de C macros:
typedef unsigned (__stdcall *PTHREAD_START) (void *);

Als je de syntax van typedef bekijkt snap je die meteen, maar kijk je naar deze typedef dan raak je wellicht in de war, want waar begint het nieuwe type en waar houdt het ge-aliaste type op? (dit defineert een macro "PTHREAD_START" dus die staat midden in de alias )

Wellicht wat gemeen voorbeeld, maar in de stl zijn zat voorbeelden terug te vinden van erg leuk C++ gebruik waar de gemiddelde C++ programmeur toch wel even naar zal staren van "erm... ik dacht dat ik de syntax begreep".

[ Voor 5% gewijzigd door EfBe op 31-05-2004 11:40 ]

[MaxxRide]

Oke misschien moet er een middenweg gezocht worden? Iets als:

Commentaar toevoegen doe je op een abstracte manier bij functies/ classes etc, hierbij verwijs je ook naar de documentatie van het design. Verder voeg je commentaar toe bij code constructies die niet alledaags zijn en niet eenduidig voor zichzelf spreken (neem b.v. die typedef/ macro's in C, maar een toekenning van een waarde aan een int is dan niet nodig).

[Alarmnummer]

Pinda schreef op 31 mei 2004 @ 11:53:
Oke misschien moet er een middenweg gezocht worden? Iets als:

Commentaar toevoegen doe je op een abstracte manier bij functies/ classes etc, hierbij verwijs je ook naar de documentatie van het design. Verder voeg je commentaar toe bij code constructies die niet alledaags zijn en niet eenduidig voor zichzelf spreken (neem b.v. die typedef/ macro's in C, maar een toekenning van een waarde aan een int is dan niet nodig).

Het is belangrijk om te weten wat een functie doet, maar voor het testen is het ook erg belangrijk om te weten wat ie niet doet en wanneer het misgaat. Daarom vind ik het ook erg belangrijk dat beschreven wordt wat er allemaal mis kan gaan en onder welke voorwaarden dit gebeurt.

[MaxxRide]

@alarmnummer: als het ware een uitgebreide vorm van pre en post condities (deze vertellen enkel van welke beginstaat naar welke eindstaat de functie bepaalde variabelen moet zetten)?

Ik denk dat het ook erg belangrijk is dat je weet wat een functie wel en idd ook vooral niet doet. Dit lijkt me ook in het commentaar te moeten staan. Ik zou het commentaar alleen wel beperken tot de "scope" van de functie. En voor een meer abstractere blik en de invloeg op het gehele systeem verwijzen naar de design dox.

[flowerp]

EfBe schreef op 31 mei 2004 @ 10:07:
[...]

De syntax van C++ is dermate uitgebreid dat je er niet vanuit mag gaan dat iedere lezer C++ moet kennen, daar het gros van de C++ ontwikkelaars niet voor 100% de syntax kent. (maar int i=4; is wel erg suf)

Dat is inderdaad zo, ik gebruik nu zelf C++ sinds 1995, maar nog steeds kom ik af en toe constructies tegen die ik nog nooit gebruikt hebt. Het slapste voorbeeld is overigens do-while, die heb ik in al mijn +-20 jaar dat ik programmeer nog nooit gebruikt

Het is wellicht ook handig af en toe het Engelse woordenboek erbij te pakken (CreatOr )

Tsja, dat zou wel goed zijn voor mij. Ik pak overigens inderdaad af en toe een engels woordenboek erbij. Wat dat betreft zou een spellchecker in mijn IDE ideaal zijn (of een cursus engels )

Klopt, het is alleen de vraag of je ontwerpbeslissingen, want daar heb je het hier over, alleen in de code moet opnemen, omdat je ze nooit en te nimmer meer terugvindt wanneer je ergens anders iets moet wijzigen wat afhangt van een ontwerpbeslissing in een andere functie en die beslissing is alleen in de code verwoord.

Ik ben er zelf een zeer groot voorstander voor om een design document in lock-step te ontwikkelen met de code. Designs veranderen namelijk altijd, en het beschrijven van alle beslissingen vind ik erg belangrijk en is vaak ook essentieel om grotere verbanden in code te zien. In tegenstelling tot veel andere andere ontwikkelaars, vind ik het ook leuk om een ontwerp te documenteren, inclusief (UML) diagrammen, algoritmes die stap voor stap uitgelegd worden enz. Meestal stop ik in de code een zeer korte samenvatting van de relevante sectie in de design documentatie. Tevens hou ik een developper history bij waar ik per dag als een soort dagboek bij hou wat ik heb gedaan en waarom. Hier kan ik heel informeel en slordig kleine beslissingen noteren.
Ik werk nu bij een bedrijfje waar geen requirements en design documenten worden bijgehouden en daar wordt ook geen tijd voor ingeruimt. Naar mijn mening gaat dit op de langere termijn echt problemen geven.

[MaxxRide]

Ik heb hetzelfde probleem wat betreft het maken van documentatie. Maar daar ben ik vrij simpel over: Ik ben pas met programmeren als er een document is, dat maak ik vaak zelf. Ik beschrijf het vaak met UML en doe dit vaak met een papiertje en een potloodje. Dit komt vervolgens in mijn map voor het project terecht. Ik hou vaak ook op scratch bij welke (kleine) beslissingen ik in de code maak.

Vaak verwijs ik in de code naar mijn ontwerp. Hieruit is goed op te maken wat de gevolgen zijn van het veranderen van code op een bepaald punt voor de rest van het systeem.

[whoami]

flowerp schreef op 31 mei 2004 @ 12:57:
[...]


Dat is inderdaad zo, ik gebruik nu zelf C++ sinds 1995, maar nog steeds kom ik af en toe constructies tegen die ik nog nooit gebruikt hebt. Het slapste voorbeeld is overigens do-while, die heb ik in al mijn +-20 jaar dat ik programmeer nog nooit gebruikt

Het is dan wel off-topic, maar dit vind ik vreemd. Ik heb al vaker gehoord van mensen dat een do - while nutteloos is, terwijl dat dit eigenlijk niet zo is.
Een do - while is significant anders dan een while do. Je kan wel een do - while schrijven als een while - do, maar dan heb je zowiezo extra code nodig.

In tegenstelling tot veel andere andere ontwikkelaars, vind ik het ook leuk om een ontwerp te documenteren, inclusief (UML) diagrammen, algoritmes die stap voor stap uitgelegd worden enz.

UML diagrammen moet je hebben voordat je code geschreven hebt, niet daarna.

[flowerp]

EfBe schreef op 31 mei 2004 @ 09:45:
Omdat het runnen van een testprogramma je precies de waarden geeft waar je naar op zoek bent (of dus niet en dan heb je een bug) maar in de debugger het vele malen langer duurt voordat je die waarden hebt. Een assert is echt veel sneller dan door een lap code steppen en dan een local's value checken.

Asserts gebruik ik natuurlijk ook, maar om sommige condities te checken is een debugger echt razendsnel hoor. Ik schrijf code, laten ze zeggen +- 30 minuten en heb daarna in mijn hoofd wat de waarden en het verband van een stuk om 10 variablen moeten zijn. Ik zet een breakpoint, start de debugger, inspecteer de variablen, en stop de debugger weer. Alles bij elkaar kost het mischien een minuutje. Momenteel werk ik met Eclipse aan een java project. Omdat er telkens op de achtergrond gecompiled wordt staat de debugger zeer snel voor mijn neus.

Aan een C++ project waaraan ik hiervoor werkte ging het over het algemeen ook snel (incremental building enz), maar als je wat ongelukkige dependencies veranderde kon het wel eens wat langer duren omdat er wat meer hergecompiled moest worden, maar meer dan een extra minuut tijd kostte het zelden (of je moet echt iets -heel- ongelukkigs veranderen zodat echt alles hergecompiled moet worden).

Waarom plaats je geen assert?

Die gebruik ik dus ook

Ten eerste lijkt me dat onbegonnen werk bij een wat ingewikkelde datastructuur en ten tweede is het me onduidelijk waarom je niet middels programmatuur test, immers een paar regels code maken GEEN fouten

Tsja, jij -weet- dat dat niet klopt, en toch schrijf je het op? In regels code, zelfs een paar, zelfs in eentje kunnen net zo goed fouten zitten.
Als ik zeer snel een een groepje variabelen wil inspecteren heb ik ze iha sneller voor mijn neus in een watch window dan dat ik uberhaupt ze in een printf kan intikken.

, echter jij die naar een locals windowtje staart maakt GEHEID een fout af en toe, los van het feit dat het mega-veel tijd kost.

In veel gevallen is het geen kwestie van fouten maken, ik wil snel een overzicht hebben van wat alles doet. Het geeft me dus inzicht. In andere gevallen controlleer ik inderdaad en dan kan ik fouten maken ja. Dat ik nog nooit officieel unit testing heb gedaan is mischien wel een minpuntje waar ik zoals gezegd aan ga werken. Het verschil is echter niet zo mega groot, daar ik wel gewoon test functies gebruikt, of zelfs test objecten die een interface helemaal doornemen. Het enige verschil is dat ik deze test code nu naar het unit testing framework zal moeten verplaatsen.

snelle inspectie van de state dmv een debugger is een farce. Als ik mn 3MB grote codebase met een debugger moet doorsteppen ben ik een dag bezig zeg.

Ja, duh, dat is een non-statement en dat weet je zelf ook. Mijn codebase is net over de 2MB, maar ik ga toch niet -alles- doorsteppen als ik 4 values in 1 enkele functie wil controleren? Als ik dat zou gaan doen dan haal ik het zeker niet binnen een dag, volgens mij nog niet eens binnen een week.

Overigens vind ik je vrij zelfingenomen overkomen, terwijl je de ballen verstand hebt van de tools die tot je beschikking staan.

Op het gebied van testen kan ik mischien nog dingen leren, maar de ballen verstand ervan hebben is toch echt niet van toepassing. Mischien dat ik wat eigenaardigheidjes heb, maar waar ik ook begin, binnen de korste tijd komen de mensen naar mij toe voor vragen en zit ik van alles voor te schrijven en uit leggen. Ik ben dan ook al zeer lang bezig en ben dag en nacht met mijn vak in de weer.

Ze zijn zeker nuttiger dan veel tijd verprutsen in een debugger om visueel de state van het programma te gaan bekijken.

Ik heb het wel gedaan, correctheidsbewijzen opstellen (hoewel ik het nu niet meer zou kunnen waarschijnlijk), maar de tijd die er in gaat zitten is zo enorm, dat je het eigenlijk ook alleen voor hele kleine, hele critische stukjes code doet.

[flowerp]

whoami schreef op 31 mei 2004 @ 13:22:
[...]

Het is dan wel off-topic, maar dit vind ik vreemd. Ik heb al vaker gehoord van mensen dat een do - while nutteloos is, terwijl dat dit eigenlijk niet zo is.
Een do - while is significant anders dan een while do. Je kan wel een do - while schrijven als een while - do, maar dan heb je zowiezo extra code nodig.

[...]

UML diagrammen moet je hebben voordat je code geschreven hebt, niet daarna.

Ja en nee. In een ideale wereld doe je eerst aan requirements engineering, maak je een requirements document, ga je met je design aan de slag waarin UML diagrammen komen over je design enz enz. We kennen het hele traject allemaal wel hier.

In de echte wereld veranderen requirements, er gaat tijd over het hele traject heen en er moeten 'opeens' nieuwe features bij komen, 'opeens' vindt een klant dat x en y ook moet kunnen terwijl je had afgesproken dat dat juist niet zou moeten kunnen.

Ook komt het voor dat diegene die het design opstellen niet perse de beste coders zijn, bij de echte implementatie blijken dingen helemaal niet zo handig te werken als het design voor deed komen. Wellicht dat bij hele grote bureaucratische bedrijven (bv IBM) het design wel echt 100% vast staat en er in de implementatie fase nix meer aan mag veranderen.

Bij kleinere bedrijven echter werk je ook wel met wat wel eens round-robbin engineering genoemt wordt, of incremental developping (zie ook bv spiral model enz); Je begint met basis requirements, basis design, en basis (prototype) implementatie. Vervolgens laat je het prototype zien aan klanten of managers, redeneert hierover, stelt nieuwe/aangepaste requirements op, past je design aan en implementatie aan enz enz.

In het kort kom het er op neer dat je UML diagrammen (of OMG, of wat je ook gebruikt), niet alleen een specificatie zijn voor je code, maar ook een documentatie. De ontwikkeling van beide volgt elkaar in beide kanten op.

[Alarmnummer]

Implementatie en design moeten idd hand in hand gaan. Implementatie is namelijk een emperische methode om te kijken of je ontwerp echt doet wat het moet doen en je komt er dan achter dat bv de performance te slecht is. Dat moet weer terug gekoppeld worden aan het design.

Verder ben ik niet zo`n liefhebber van UML. Het is handig voor documentatie in grote lijnen, maar lowlevel UML is fout. Voor iedereen die UML maakt dat 1 op 1 met je code overeen komt, pak alsjeblieft een goed UML boek en dan zul je zien dat je dit dus absoluut niet moet doen. UML is handig in grote lijnen, maar je gaat niet tot op het allerlaagste nivo met UML werken.

Misschien vinden jullie dit trouwens ook nog wel een leuk artikel:
http://www.martinfowler.c...tedComputing/duckling.pdf

[flowerp]

Alarmnummer schreef op 31 mei 2004 @ 13:51:
UML is handig in grote lijnen, maar je gaat niet tot op het allerlaagste nivo met UML werken.

Inderdaad niet. Je kunt in UML in principe zelfs een body van een functie grafisch weergeven. UML ligt in dat geval op het randje van een grafische programmeertaal. Dat is echter geenzins de bedoeling van UML. Het gaat er juist om, om die verbanden weer te geven die wel aanwezig zijn in de code, maar die je gewoonweg niet zo snel ziet. In het geval van een van de simpelste diagrammen, het class diagram is het dikwijls al overbodig om alle function signatures op te nemen.

[MaxxRide]

Ik gebruik UML altijd meer om in grote lijnen de relaties tussen classes en de voortgang van sommige (complexe) transacties weer te geven (zodat je b.v. weet wat de verwachte volgende stap is in het systeem). Verder vind ik het idd onnodig om alle functiedefinites variabelen etc te noemen. Soms is dit wel handig bij b.v. de definitie van een interface. Maar vooral in grote lijnen is het een ideaal hulpmiddel!

[igmar]

flowerp schreef op 31 mei 2004 @ 00:13:
Wat ik bv bedoel is zoiets als:

C++:

if (modelTransition == true) {
  // -user- requested model transition, so we need to restore the original model 
  // since the transition needs to have flowX and flowY data that is present only
  // in the original model. Transitions never re-execute
  // any model creating command themselves. For all other operations, this original 
 //model is not needed and thus not restored.
  modelCreater* ModelCreater = new ModelCreater();
  modelCreater->setState(this);
  stateTable.resync(modelCreater);
  // ...
}

Dit is dus onderdeel van code die een state restore doet. Je ziet aan de code zelf wel dat een transitie een nieuw model nodig heeft, maar waarom?

Dit valt bij mij onder : Dit snap ik niet meer na 2 maand niet meer naar de code kijken. Dit soort dingen zet ik zelf ook in de code.

De comments zeggen dat dus. Sommige programmeurs vinden dit soort commentaar erg overdreven; je kunt namelijk ook in de code voor een transitie kijken waarom er een origineel model nodig is.

Dat kan ja, maar vind ik zelf geen reden om geen commentaar te gebruiken.

Ik zelf vind dit echter veel makkelijker omdat ik zo een stuk code in 1 maal door kan lezen zonder telkens naar andere files te springen, waarin ik ook weer naar weer andere moet gaan enz...

Precies. Liggen we toch nog op een lijn

[igmar]

EfBe schreef op 31 mei 2004 @ 09:55:
Het is een zeer juiste benaming, en vertelt precies wat het doet, een string naar int converteren, iets dat je zelf juist wilt propageren. Overigens is dat geen hungarian, hungarian is iets als:

int m_iFoo;
bool m_bFlag;

Goed, we missen de type prefixes, MaarDieHooflettersInDeNamen blijven_wel_erg_onnatuurlijk_lezen.

Je snapt het ?

Errorchecking is niet nodig omdat de functie geacht wordt juist te werken, niet omdat het niet kan.

Onzin, er is in het geval van atoi() geen errorchecking mogelijk, en errorchecking heeft niks te maken met of een functie geacht wordt juist te werken. Een functie kan juist werken, maar toch errors produceren. In het geval van atoi() :

The atoi() function converts the initial portion of the
string pointed to by nptr to int. The behaviour is the
same as

strtol(nptr, (char **)NULL, 10);

except that atoi() does not detect errors.

[EfBe]

igmar schreef op 31 mei 2004 @ 16:44:
Goed, we missen de type prefixes, MaarDieHooflettersInDeNamen blijven_wel_erg_onnatuurlijk_lezen.

Je snapt het ?

Nee, die underscores lezen makkelijk. HoofdLettersInNamen wordt CaMel casing genoemd. Het is wellicht even wennen, maar IMHO beter. (en ook voorschrift in zowel Java als .NET, net zoals unix-C veelal voorschrijft lowercase underscore galore )

Onzin, er is in het geval van atoi() geen errorchecking mogelijk, en errorchecking heeft niks te maken met of een functie geacht wordt juist te werken. Een functie kan juist werken, maar toch errors produceren. In het geval van atoi() :

Niet spijkers op laag water zoeken. Als ik een functie aanroep met valide input, verwacht ik valide output en geen error. Als je non-valide input geeft krijg je wellicht een error, maar dan moet je maar geen non-valide input in een functie stoppen, tenslotte werkt de functie alleen voor de voor die functie valide input.

Voorbeeld:
public int div(int a, int b)

Welnu, deze te gekke functie deelt a door b middels een integer div. b==0 is geen valide input.

[mbravenboer]

Om even op het de zwaarte van testen door te gaan: meten is weten . Gebruikt iemand code coverage tools om te kijken hoe goed de unit tests de code dekken?

[flowerp]

mbravenboer schreef op 31 mei 2004 @ 19:00:
Om even op het de zwaarte van testen door te gaan: meten is weten . Gebruikt iemand code coverage tools om te kijken hoe goed de unit tests de code dekken?

Ik gebruik geen expliciete unit tests, maar gebruik wel profilers om te zien hoe de executietijd verdeelt is tijdens handmatige testen en of er niet ergens onevenredig veel tijd besteed wordt.

[EfBe]

mbravenboer schreef op 31 mei 2004 @ 19:00:
Om even op het de zwaarte van testen door te gaan: meten is weten . Gebruikt iemand code coverage tools om te kijken hoe goed de unit tests de code dekken?

Nog niet Ze zitten/komen in vs.net 2005 (vs team system) btw.

[flowerp]

EfBe schreef op 31 mei 2004 @ 20:36:
[...]

Nog niet Ze zitten/komen in vs.net 2005 (vs team system) btw.

Er zat ook een profiler in VS6, maar die werd nogal slecht gevonden en verwijderd in vs.net 2002 & 2003. Wel heeft MS een deal gesloten voor een 3rd party profiler. Je kunt dan een zogenaamde community edition downloaden met gereduceerde functionaliteit.

Icm met de intel compiler (vtune etc) kun je ook van profilers gebruik maken.

[whoami]

Heb je het hier over de DevPartner Profiler?
Ik heb 'm vorige week gedownloaded, maar nog niets mee gedaan. Hoe bevalt het?

[igmar]

EfBe schreef op 31 mei 2004 @ 16:56:
Nee, die underscores lezen makkelijk. HoofdLettersInNamen wordt CaMel casing genoemd.

Het PHP core team noemt het 'Sucky Caps'

Het is wellicht even wennen, maar IMHO beter. (en ook voorschrift in zowel Java als .NET, net zoals unix-C veelal voorschrijft lowercase underscore galore )

Het is minder leesbaar, maar toch beter ? Dat vat ik even niet.

Niet spijkers op laag water zoeken. Als ik een functie aanroep met valide input, verwacht ik valide output en geen error. Als je non-valide input geeft krijg je wellicht een error, maar dan moet je maar geen non-valide input in een functie stoppen, tenslotte werkt de functie alleen voor de voor die functie valide input.

Daar verschillen we dan van mening in : Een functie moet in staat zijn om invalid input af te handelen, tenzij het ontwerp zegt dat invalid input niet voorkomt. met atoi() zijn de zaken complexer : De functie kan 0 teruggeven, maar je kan niet zien of dat incorrecte input is, of dat de input de string "0" is.

Voorbeeld:
public int div(int a, int b)

Welnu, deze te gekke functie deelt a door b middels een integer div. b==0 is geen valide input.

0 als input is gewoon een geldige int, alleen levert delen door 0 geen geldige waarde op (ook niet geheel correct : Het levert een oneindig getal op, die niet weergegeven kan worden. Ik zet zelf assert()'s in het geval dat een input niet voor mag komen.

[flowerp]

whoami schreef op 31 mei 2004 @ 22:15:
Heb je het hier over de DevPartner Profiler?
Ik heb 'm vorige week gedownloaded, maar nog niets mee gedaan. Hoe bevalt het?

Tijdje geleden voor het laatst gebruikt. Voor dat profiling gebruikt kan worden moet er 'instrumentation' plaatsvinden: het toevoegen van hooks in jouw code. Dat is een redelijk langzaam process als je een niet al te snelle computer hebt en een grote code base.

Voorderest werkt het wel redelijk, je kunt na een run netjes door je functies heen navigeren waarbij je verschil kunt zien tussen tijd in de functie zelf, in alle kinderen en systeem functie tijd vs tijd in eigen functies. Iets wat ik jammer vond is dat ie niet goed lijkt om te gaan met threads. In mijn project werd erg veel gebruik gemaakt van threads. Ik weet bijna zeker dat er weergegeven tijden niet klopte.

Het is echter een jaar geleden en met vs.net 2002 (C++), dus mischien is het ondertussen beter.

[.oisyn]

igmar schreef op 30 mei 2004 @ 21:52:
[...]


De constructor / destructor regel gaat gewoonweg niet altijd op, en is geen argument om tools zoals valgrind niet te gebruiken. Een kwestie van ervaring is het zeker, en ondanks het feit dat ik nog zelden leaks heb blijf ik de checks doen.

Ik doe anders zelden een delete buiten een destructor (met uitzondering van algemene memory management code) Over het algemeen gebruik ik daar smart pointers en object owners voor (is het zaakje ook gelijk exception safe)

[.oisyn]

flowerp schreef op 31 mei 2004 @ 12:57:
Dat is inderdaad zo, ik gebruik nu zelf C++ sinds 1995, maar nog steeds kom ik af en toe constructies tegen die ik nog nooit gebruikt hebt. Het slapste voorbeeld is overigens do-while, die heb ik in al mijn +-20 jaar dat ik programmeer nog nooit gebruikt

Zoals whoami al zegt, een do-while is essentieel anders dan een while. Eigenlijk is de while degene die overbodig is, aangezien je while (conditie) ook simpelweg kunt schrijven als for (; conditie; ). Een do-while lukt echter niet, en is alleen maar te herschrijven als een for (;;) of while (1), met een handmatige if aan het eind van de lus. Sowieso zorgt een do-while altijd voor ten minste 1 iteratie, en bovendien wordt er bij een continue met de volgende iteratie verder gegaan zonder eerst de conditie te checken. Toegegeven, ik gebruik een do-while ook niet zoveel als een while, maar ik gebruik 'm wel degelijk en ik ken haar nut.

Offtopic:

EfBe schreef op 31 mei 2004 @ 11:39:
(dit defineert een macro "PTHREAD_START" dus die staat midden in de alias )

Het definieert een type alias, geen macro. Type aliases en macro's zijn 2 hele verschillende dingen (dit voorbeeld kan zelfs niet eens met een #define gedefinieerd worden)

igmar schreef op 31 mei 2004 @ 23:01:
Het PHP core team noemt het 'Sucky Caps'

En ik noem het PHP core team 'sucky'

[Alarmnummer]

En zullen we weer ontopic gaan? Topics kapen, ok..maar niet die van mij

[ Voor 6% gewijzigd door Alarmnummer op 01-06-2004 07:43 ]

[EfBe]

.oisyn schreef op 01 juni 2004 @ 01:02:
Offtopic:
Het definieert een type alias, geen macro. Type aliases en macro's zijn 2 hele verschillende dingen (dit voorbeeld kan zelfs niet eens met een #define gedefinieerd worden)

Jaja Type alias inderdaad. My bad.

[seweso]

Persoonlijk test ik meestal tussen-tijd al mijn functies en classen door deze gewoon vanuit het command-window aan te roepen. Gewoon om te zorgen dat ik een goed gevoel over de functie krijg, waarbij het vaak nodig is om extra aandacht te geven aan de mogelijke uitzonderings gevallen te geven.

Maar die werkwijze is alleen te hanteren bij een goed opgezet programma. Dus als het maar een beetje op spaghetti gaat lijken dan moet je meestal maar hopen dat alles betrouwbaar gaat/blijft werken. Ik heb namelijk wel eens programma's gehad die na een aantal aanpassingen helemaal uit elkaar vielen van de bugs, en totaal onwerkbaar werden. Maar dat waren dan meestal een quick&dirty project, die meestal geheel vervangen dienen te worden.

Testen doe je trouwens in mijn optiek niet alleen om bugs uit je applicatie te halen, het is tevens dé manier om je ontwerp te valideren. Immers als je bij het testen van je functies/classen te omslachtig te werk dient te gaan (dus simpelweg erg veel code voor je test-case nodig hebt) dan moeten er zeker nog wat dingen versimpeld worden.

Testen is dus voor mij een onderdeel van het ontwikkel-proces en niet een stap welke alleen tijd kost en niks oplevert. En door tussen-tijds de testen is het minder erg als je opeens tegen een boom aan rijd.


Deze manier van testen leid automatisch tot:
- Extreem kleine functies en classen (gemiddeld 10 regels code per functie/methode, anders zijn er teveel mogelijke inputs mogelijk).
- Elke functie/methode als een zwarte doos, als er x in gaat móet er y uitkomen (anders weet je niet of een test het goede resultaat heeft gegeven ).
- Meer herbruikbare code (dan hoef je immers niet telkens ongeveer hetzelfde te testen)
- Alleen verwijzingen naar minder specifieke code (voorkomt ontestbare spaghetti code)
- Zelf documenterende code.

[igmar]

.oisyn schreef op 01 juni 2004 @ 00:41:
Ik doe anders zelden een delete buiten een destructor (met uitzondering van algemene memory management code) Over het algemeen gebruik ik daar smart pointers en object owners voor (is het zaakje ook gelijk exception safe)

Da's inderdaad nog beter, al blijf ik erbij dat een extra check door iets als valgrind geen kwaad kan

[igmar]

.oisyn schreef op 01 juni 2004 @ 01:02:
En ik noem het PHP core team 'sucky'

Ik moet desondanks de eeste nog tegencomen die valide argumenten kan geven voor het gebruik Hongaarse notatie, en in mindere mate CaMel casing aka Studdly Caps aka Sucky Caps. Ik ben fanatiek aanhanger van een (grote) groep die het wijgert te gebruikern (al wel in mindere met Camel casing).

[.oisyn]

igmar schreef op 01 juni 2004 @ 11:49:

Ik moet desondanks de eeste nog tegencomen die valide argumenten kan geven voor het gebruik Hongaarse notatie, en in mindere mate CaMel casing aka Studdly Caps aka Sucky Caps. Ik ben fanatiek aanhanger van een (grote) groep die het wijgert te gebruikern (al wel in mindere met Camel casing).

Wat je het liefst hebt is natuurlijk volledig je eigen keuze, ik reageerde alleen maar op je argument dat het PHP Core team iets vindt. Als er wel iets is wat ik niet serieus neem dan is dat het "PHP Core team" wel . Consistentie en elegantie komt iig niet in hun vocabulaire voor, laat staan logische semantiek

Overigens ben ik zelf wel fan van camelcasing, java-style (dus functies en variabelen beginnen met een kleine letter), maar ik mix ook wel C++ STL style naamgeving erdoorheen. Echte solide klassen CamelCase ik, maar dingen als PODs en enums schrijf ik over het algemeen in lowercase met een _t erachter, en containers zijn meestal alleen lowercase (Beetje raar dat als je een std::vector en een std::list hebt, dat je dan wel ineens een Oisyn::BinaryTree zou hebbeb. Een oisyn::binarytree past dan beter ). Namespaces doe ik overigens ook altijd lowercase, en niet van die lange namen (omdat ik ze vaak gewoon volledig typ, en zelden gebruik maak van using directives en declarations)

[ Voor 5% gewijzigd door .oisyn op 01-06-2004 13:56 ]

[Verwijderd]

EfBe schreef op 31 mei 2004 @ 09:45:

Ik ben opgegroeid met de gnu commandline debugger op een VAX, ik weet echt wel hoe je programma's moet testen en debuggen en dat er veel tools zijn die veel sneller testen of pre en post condities (want dat ben je toch aan het testen) kloppen dan een debugger. Sterker, tijdens veel debug sessies start ik echt geen debugger op. En nee ik gebruik geen printf's meer.

Ik ben zelf drs. informatica met 4 jaar werkervaring, en ben toch niet op het laagste niveau bezig. Natuurlijk doe ik aan unit testing, af en toe zeer uitgebreid zelfs. Toch maak ik ook gebruik van een debugger voor een snelle test. Sterker nog, ik begin niet eens aan het schrijven van test code als ik niet eerst de code die ik wil testen:

1 Tenminste 1 maal gecompiled heb
2 Snel met een debugger de belangrijkste variabelen gechecked heb

Voor mij is een debugger een zeer handige tool om mijn code snel te controleren en eventueel de stomste dingen er meteen uit te halen.

Pas als de code een beetje stable is, ga ik er uitgebreid unit testen voor schrijven. De debugger komt gewoon een fase daarvoor.

Overigens vind ik je vrij zelfingenomen overkomen, terwijl je de ballen verstand hebt van de tools die tot je beschikking staan.

Volgens mij heb jij ook de ballen verstand van dingen. Iedereen met praktijk ervaring weet dat een dergelijke manier van controleren handig is als de code nog heel jong is. Unit testen hebben in een heel vroeg stadium IMHO nogal weinig zin.

Als jij een debugger stom vindt dan zou je het gewoonweg kijken naar je code ook stom moeten vinden. In zekere zin komt een early run daarop neer; Bij het bekijken van een stukje code vul je ook in gedachten wat waarden in, loopt een stukje door in gedachten, en denkt na over de uitkomst. Een run met de debugger maakt dit concreet. Met unit tests pak je ook niet zomaar even een stukje code midden in een functie.

[curry684]

igmar schreef op 31 mei 2004 @ 23:01:
[...]

0 als input is gewoon een geldige int, alleen levert delen door 0 geen geldige waarde op (ook niet geheel correct : Het levert een oneindig getal op, die niet weergegeven kan worden. Ik zet zelf assert()'s in het geval dat een input niet voor mag komen.

Je originele stelling klopt, je 'correctie' niet. De enige manier om een deling door 0 te simuleren is door hem te benaderen, en afhankelijk van de richting van benaderen kom je oftewel op plus of min oneindig uit. Ergo het is niet eens benaderbaar.

Verder is je stelling dat camelCase of PascalCase (camelCase heeft een leading non-caps, ooit een kameel met een bult op z'n kont gezien? ) niet populair zou zijn volstrekt onzin: ieder stuk bedrijfssoftware dat ik ooit heb gezien hanteert het. Leuk dat het PHP core team het niet blijkbaar als enige in deze wereld niet mooi vind, maar daar hecht ik niet echt veel waarde aan totdat ze een fatsoenlijke taal leren opzetten.

[Alarmnummer]

Pas als de code een beetje stable is, ga ik er uitgebreid unit testen voor schrijven. De debugger komt gewoon een fase daarvoor.

Ik pak de meest stomme fouten er uit met unit testen. Naarmate ik langer achter mijn pc zit, en hoe meer werk ik heb verzet, hoe meer stomme fouten er in komen. Unit testen is voor mij de manier om deze kleine etterbakjes er uit te peuteren. Ik heb zelf een hele fijne debugger bij mijn IDE, maar ik met eerlijk toegeven dat ik hem nooit gebruik.

Volgens mij heb jij ook de ballen verstand van dingen. Iedereen met praktijk ervaring weet dat een dergelijke manier van controleren handig is als de code nog heel jong is. Unit testen hebben in een heel vroeg stadium IMHO nogal weinig zin.

Juist niet. Hoe jonger de code is, hoe beter unittesting is voor de 'controleren' Met een unittest is het juist zo handig dat je niet een compleet systeem hoeft te hebben om het in te testen, maar dat je een enkel object of zelfs een enkele methode kunt doorfluiten. Vandaar ook 'unit' test: de kleinste eenheid in je systeem: een methode. In principe als je al op meerdere objecten tegelijk bezig bent, zit je al aan de integration tests.

Als jij een debugger stom vindt dan zou je het gewoonweg kijken naar je code ook stom moeten vinden.

Het is dat het zo raar staat maar anders zou ik er behang van laten maken zodat ik er de hele dag naar kan kijken

In zekere zin komt een early run daarop neer; Bij het bekijken van een stukje code vul je ook in gedachten wat waarden in, loopt een stukje door in gedachten, en denkt na over de uitkomst. Een run met de debugger maakt dit concreet. Met unit tests pak je ook niet zomaar even een stukje code midden in een functie.

Ik ben het met je eens dat je minder makkelijk in een functie kunt kijken. Maar over het algemeen zijn mijn functies dermate klein dat ik daar niet zo vaak de behoefte aan heb. Ik test het van buitenaf op een aantal testscenario`s en dan is het kijken of het resultaat/verandering-aan-de-omgeving klopt.

[ Voor 5% gewijzigd door Alarmnummer op 02-06-2004 07:17 ]

[Alarmnummer]

En handige techniek om je testen uit te voeren is om niet zozeer positief te testen, maar om te testen om je je code ook om zeep kan helpen. Dan ga je veel agressiever bezig om gaten in je code te vinden en eventueel af te schermen (met exceptions bv).

[Verwijderd]

Alarmnummer schreef op 02 juni 2004 @ 07:15:
[...]

Ik pak de meest stomme fouten er uit met unit testen. Naarmate ik langer achter mijn pc zit, en hoe meer werk ik heb verzet, hoe meer stomme fouten er in komen.

Je bedoelt dat als je moe wordt dat je dan rare fouten gaat maken? Dan heb ik ook wel eens, zeker aan het eind van een werk dag als het ook nog eens druk is geweest en ik vaak onderbroken wordt voor problemen in hele andere stukken code dan waar ik nu aan werk.

Af en toe programmeer ik dan 'op de automatische' piloot, heel raar, maar dan heb ik gewoon hele stukken code ingetikt zonder er echt bij na te denken. Een beetje zoals je een vaste route naar huis rijdt zonder na te denken. Als dat gebeurt weet ik dat het tijd is om naar huis te gaan :-) (en de code te wisssen)

Unit testen is voor mij de manier om deze kleine etterbakjes er uit te peuteren. Ik heb zelf een hele fijne debugger bij mijn IDE, maar ik met eerlijk toegeven dat ik hem nooit gebruik.

For the record, welke IDE gebruik je dan?

Het is dat het zo raar staat maar anders zou ik er behang van laten maken zodat ik er de hele dag naar kan kijken

Nou, op de universiteit waar ik zat (UL) hangen er best wel een aantal algorithmes aan de muren hoor en een stukje code hangt er ook wel af en toe :-)

Ik ben het met je eens dat je minder makkelijk in een functie kunt kijken. Maar over het algemeen zijn mijn functies dermate klein dat ik daar niet zo vaak de behoefte aan heb.

Natuurlijk, maar je wilt ook weer niet voor elk stukje code een aparte functie schrijven. Als ik nog een beetje aan het 'code-schetsen' ben wil ik wel eens kijken of alles tot een bepaald stukje een beetje aan de verwachtingen voldoet. Asserts helpen natuurlijk ook in zo'n geval.

Waar ik de debugger ook nog wel eens voor wil gebruiken is om een beeld van code te krijgen die ik niet zelf geschreven heb. In dat geval step ik deze een beetje snel door om een beetje een idee van de samenhang te krijgen.

[Alarmnummer]

Verwijderd schreef op 02 juni 2004 @ 22:20:
For the record, welke IDE gebruik je dan?

Intellij IDEA en Codeguide (met een hele krachtige debugger schijnt het:)

Codeguide debugger

Nou, op de universiteit waar ik zat (UL) hangen er best wel een aantal algorithmes aan de muren hoor en een stukje code hangt er ook wel af en toe :-)

*voelt zich eindelijk begrepen*..

Natuurlijk, maar je wilt ook weer niet voor elk stukje code een aparte functie schrijven. Als ik nog een beetje aan het 'code-schetsen' ben wil ik wel eens kijken of alles tot een bepaald stukje een beetje aan de verwachtingen voldoet. Asserts helpen natuurlijk ook in zo'n geval.

Gecompliceerde functies staan bij mij vol met asserts.

Waar ik de debugger ook nog wel eens voor wil gebruiken is om een beeld van code te krijgen die ik niet zelf geschreven heb. In dat geval step ik deze een beetje snel door om een beetje een idee van de samenhang te krijgen.

Ik heb tot zover het geluk gehad dat ik altijd goeie code van anderen heb kunnen gebruiken of het kunnen wijgeren/weggooien.

[igmar]

curry684 schreef op 02 juni 2004 @ 02:10:
Je originele stelling klopt, je 'correctie' niet. De enige manier om een deling door 0 te simuleren is door hem te benaderen, en afhankelijk van de richting van benaderen kom je oftewel op plus of min oneindig uit. Ergo het is niet eens benaderbaar.

Dat zal d'r vanaf hangen of een deling door 0 wiskundig is definieert, en dat kun je beter niet aan mij vragen

Verder is je stelling dat camelCase of PascalCase (camelCase heeft een leading non-caps, ooit een kameel met een bult op z'n kont gezien? ) niet populair zou zijn volstrekt onzin: ieder stuk bedrijfssoftware dat ik ooit heb gezien hanteert het.

Omdat de meeste bedrijfssoftware voor Windows is geschreven ? Ik zie het bijna nooit in OSS C code, wel bv in OSS C++. Verder is het een kwestie van smaak : Ik zelf gebruik het niet en ga het ook niet gebruiken, het is mij iig niet zo aangeleerd. Indien een project het wel gebruikt zal ik me daar gewoon bij aansluiten, net zoals ik alle codingstyles in acht neem.

Leuk dat het PHP core team het niet blijkbaar als enige in deze wereld niet mooi vind, maar daar hecht ik niet echt veel waarde aan totdat ze een fatsoenlijke taal leren opzetten.

Sja.. Ik noem de kernel, libc, openssl, zowat alle GNU tools toch geen 'kleine' projecten, en die gebruiken het niet. Ik zelf val er niet zo erg over, het enige waar ik wel een probleem mee heb zijn type prefixes, aka Hongarian Notation. Geef mij overigens maar Python of Java

[EfBe]

Verwijderd schreef op 02 juni 2004 @ 00:05:
Ik ben zelf drs. informatica met 4 jaar werkervaring, en ben toch niet op het laagste niveau bezig.

Ik ben ing. informatica en 10 jaar werkervaring en ik ben ook niet op het laagste niveau bezig, maar wat heeft dit voor band met wat bediscussieerd werd?

Natuurlijk doe ik aan unit testing, af en toe zeer uitgebreid zelfs. Toch maak ik ook gebruik van een debugger voor een snelle test. Sterker nog, ik begin niet eens aan het schrijven van test code als ik niet eerst de code die ik wil testen:

1 Tenminste 1 maal gecompiled heb
2 Snel met een debugger de belangrijkste variabelen gechecked heb

Dat is een methode inderdaad. Het gaat er mij om dat men door heeft dat:
1) het algorithme dat geimplementeerd is, uberhaupt klopt
2) het algorithme dat geimplementeerd is, goed is geimplementeerd (dus code terugvertalen naar algorithme, checken of dat inderdaad het algorithme is dat geimplementeerd moest worden)
Hoe je 2) doet is aan de programmeur natuurlijk. Ik heb echter na 10 jaar echt geen debugger meer nodig om te kijken hoe code zich gedraagd. Waar ik wel een debugger voor nodig heb is de invloed van de flow van programmatuur door de applicatie, maw: method A doet iets, roept B aan en wat A deed is van invloed op B's uitkomst bijvoorbeeld. Dan kun je B controlleren, maar nooit echt goed zonder tezamen met A te checken. Dit kan dermate complex worden dat je dingen over het hoofd gaat zien.

Ik heb echter wel mn vraagtekens bij het visueel checken van state. Dit komt omdat een mens fouten maakt EN het tijdrovend is. Een setje asserts test ook state en doet dat stukken sneller EN correct in 100% van de gevallen.

Volgens mij heb jij ook de ballen verstand van dingen. Iedereen met praktijk ervaring weet dat een dergelijke manier van controleren handig is als de code nog heel jong is. Unit testen hebben in een heel vroeg stadium IMHO nogal weinig zin.

Nou, volgens mij moet jij beter lezen. Ten eerste durf ik de stelling wel aan dat ik meer van mn vak weet dan jij en ten tweede heb jij het mis in deze: een debugger is NIET bedoeld voor het checken van state, puur en alleen omdat het VISUEEL checken van state at time T:
1) traag is
2) error prone.
Nu weet ik het niet, maar volgens mij is een foutgevoelige testmanier geen juiste manier van het testen van state zoals jij dat wilt /doet

Als jij een debugger stom vindt dan zou je het gewoonweg kijken naar je code ook stom moeten vinden.

Wie zegt dat ik een debugger stom vindt? Ten eerste is het 'dom', en niet 'stom', en ten tweede is een debugger soms heel nuttig, alleen niet voor het checken van state zoals jij doet. Met een aantal asserts test je nl. ook state zonder een trage debug run te starten en in locals / watch windows values te checken.

In zekere zin komt een early run daarop neer; Bij het bekijken van een stukje code vul je ook in gedachten wat waarden in, loopt een stukje door in gedachten, en denkt na over de uitkomst. Een run met de debugger maakt dit concreet. Met unit tests pak je ook niet zomaar even een stukje code midden in een functie.

Ik doe heel veel testruns van code dat ik net heb geschreven, zodat ik weet dat het werkt. Ik heb daar echter geen debugger voor nodig en ook geen printf's. Wat denk je zelf, dat ik 3MB aan sourcecode in de debugger ga zitten verifyen? Dat is veel te tijdrovend en omdat het tijdrovend is, is de mens in algemene zin (jij wellicht niet volgens je eigen zelfbeeld) bij tijdrovende zaken minder tijd te nemen dan eigenlijk zou moeten. Een assert doet dat nooit, die doet gewoon wat hem opgedragen wordt.

[pkouwer]

even een reactie tussendoor:

Ik heb dit topic globaal doorgelezen en wat mij opvalt is dat deze testmethoden gehanteerd worden door prof. programmeurs die er hun fulltime job aan hebben. Daarnaast zijn er imho legio tweakers die niet zo ver gevorderd zijn dat ze full-time programmeren en eventueel een stapje lager. Zelf ben ik wel 3/4 vd. tijd aan het programmeren, maar wel op een lager niveau dan dit topic doet vermoeden.

Deze categorie programmeurs zijn dus eigenlijk niet gebaat bij het smijten van moeilijke termen en technologieen als het om testen gaat (=noflame). Is het niet mogelijk om ook deze mensen van informatie te voorzien hoe zij/wij de applicaties kunnen testen zonder al te ingewikkelde studies te moeten volgen.

Het is maar een idee, maar doe er je voordeel mee.

[whoami]

Als je bepaalde termen niet kent, kan je natuurlijk altijd gaan opzoeken wat die termen betekenen en wat ze inhouden.
Zo kan je er ook je voordeel meedoen.

[pkouwer]

dat is niet de essentie van mijn verhaal. Het gaat om het testen in het algemeen, niet om taalkundige betekenissen.

[bigbeng]

pkouwer schreef op 03 juni 2004 @ 11:29:
dat is niet de essentie van mijn verhaal. Het gaat om het testen in het algemeen, niet om taalkundige betekenissen.

Als je de reply van whoami goed leest (zowel taalkundig als inhoudelijk), dan zie je het werkwoord inhouden gebruikt worden. Dit betekent dus dat je moet uitzoeken wat bijvoorbeeld Unit testen inhoudt.

Misschien kun je een eigen topic openen wat meer voldoet aan je specifieke wensen? Het is namelijk zo dat de TS in principe zijn onderwerp afbakent en dat de rest daarop reageert.

[seweso]

mbravenboer schreef op 31 mei 2004 @ 19:00:
Om even op het de zwaarte van testen door te gaan: meten is weten . Gebruikt iemand code coverage tools om te kijken hoe goed de unit tests de code dekken?

Ik gebruik de coverage-profiler om te kijken waar de bottle-necks in mijn code zitten. Ik moet wel zeggen dat de coverage-profiler standaard in een modus staat waardoor je in één oog-opslag kan zien welke code níet is uitgevoerd, maar daar kijk ik eigenlijk nooit naar.

Laat is eens voor de lol even kijken... hmm ja is op zich wel handig om snel wat test-cases te verzinnen. En als ik ook zorg dat die test-cases volledig automatisch kunnen worden uitgevoerd en gecontroleerd.... ja dat zou mooi zijn. Maar de realiteit is anders. Daar heb je meestal simpelweg de tijd niet voor.

Als het gaat om hoe zwaar je test dan kun je op het niveau van NASA werken of ... helemaal niet. Waarbij één ding duidelijk is dat beide extremen geen echte optie is, en dus ligt de waarheid ergens in het midden.

Persoonlijk ben ik wel benieuwd naar de achterliggende redenen waarom sommige heel gedetailleerd moeten testen, en om wat voor een projecten dat dan gaat...

[EfBe]

pkouwer schreef op 03 juni 2004 @ 10:36:
Ik heb dit topic globaal doorgelezen en wat mij opvalt is dat deze testmethoden gehanteerd worden door prof. programmeurs die er hun fulltime job aan hebben. Daarnaast zijn er imho legio tweakers die niet zo ver gevorderd zijn dat ze full-time programmeren en eventueel een stapje lager. Zelf ben ik wel 3/4 vd. tijd aan het programmeren, maar wel op een lager niveau dan dit topic doet vermoeden.

Deze categorie programmeurs zijn dus eigenlijk niet gebaat bij het smijten van moeilijke termen en technologieen als het om testen gaat (=noflame). Is het niet mogelijk om ook deze mensen van informatie te voorzien hoe zij/wij de applicaties kunnen testen zonder al te ingewikkelde studies te moeten volgen.

Termen als unit testen lijken nieuw terwijl de achterliggende techniek al zo oud is als software development zelf. Ik denk dat als je de termen wat opzoekt op internet, de achterliggende technieken je bekend voor zullen komen en het verhaal dan duidelijk wordt. Voorbeeld: ik doe al jaren aan geprogrammeerde tests, maar gebruik geen unit tester (nog, ga ik wel doen) ook vanwege de complexiteit van sommige tests. Maar ik ben wel aan het unit testen, alleen niet via een unit testing framework. Zo moet je ook tegen deze technieken aankijken, het is veelal iets dat je al zelf gebruikt maar je kent de term niet.

[whoami]

seweso schreef op 03 juni 2004 @ 11:52:
[...]

Persoonlijk ben ik wel benieuwd naar de achterliggende redenen waarom sommige heel gedetailleerd moeten testen, en om wat voor een projecten dat dan gaat...

Euh, om ervoor te zorgen dat je software zo weinig mogelijk fouten bevat, en dat je die test-resultaten ook als een soort bewijs kunt gebruiken dat je software correct werkt misschien ?

[Alarmnummer]

seweso schreef op 03 juni 2004 @ 11:52:
[...]
Ik gebruik de coverage-profiler om te kijken waar de bottle-necks in mijn code Laat is eens voor de lol even kijken... hmm ja is op zich wel handig om snel wat test-cases te verzinnen. En als ik ook zorg dat die test-cases volledig automatisch kunnen worden uitgevoerd en gecontroleerd.... ja dat zou mooi zijn. Maar de realiteit is anders. Daar heb je meestal simpelweg de tijd niet voor.

Hoe vaak ben jij een uur kwijt om te zoeken naar een bug? En hoeveel sourcecode moet je daar gemiddeld voor door bladeren?

Als het gaat om hoe zwaar je test dan kun je op het niveau van NASA werken of ... helemaal niet. Waarbij één ding duidelijk is dat beide extremen geen echte optie is, en dus ligt de waarheid ergens in het midden.

De kunst van het unit testen is op zoek te gaan naar het punt dat unit testen uit kan. Ik ben door meer unit testen minder tijd nodig met ontwikkeling en zorg ervoor dat mijn api`s sluitend(er) zijn dan zonder testen. Maar je kunt uiteindelijk ook alles gaan testen, maar dan heb je geen tijdswinst meer. Unit testen levert mij dus tijdswinst op doordat ik een reeks testen maak waarbij ik met relatief weinig moeite de meeste bugs eruit kan pakken.

Persoonlijk ben ik wel benieuwd naar de achterliggende redenen waarom sommige heel gedetailleerd moeten testen, en om wat voor een projecten dat dan gaat...

In principe alles wat niet triviaal is. Een of andere setter of getter is imho volslagen zinloos om te testen. Maar zo gauw er een beetje meer complexiteit bij komt te kijken -> unit test.


Een voorbeeld van een unit test. De isGround functie bepaald of in een term geen variablen voorkomen.

code:

public static class IsGroundTestCase extends TestCase {

    public IsGroundTestCase(String fixture) {
        super(fixture);
    }

    public void testConstant() {
        Constant constant = new Constant(10);
        assertTrue(constant.isGround());
    }

    public void testVarTerm() {
        VarTerm varTerm = new VarTerm(new Variable("A"));
        assertFalse(varTerm.isGround());
    }

    public void testAtom() {
        Struct struct = new Struct("a");
        assertTrue(struct.isGround());
    }

    public void testNonVarStruct() {
        Struct struct = new Struct("a", Struct.TRUE, Struct.FAIL);
        assertTrue(struct.isGround());
    }

    public void testVarStruct() {
        Struct struct = new Struct("a", new VarTerm(new Variable("A")));
        assertFalse(struct.isGround());
    }
}

[ Voor 27% gewijzigd door Alarmnummer op 03-06-2004 12:21 ]