[ALG] Inchecken of testen

[bodiam]

Hallo allen,

Ik heb een kleine discussie met mijn collega's, die allen aan hetzelfde project werken. Enkele van mijn collega's willen een soort van Test Driven Software Development methodiek introduceren, maar gebrek aan ervaring speelt ons parten.
De manier waarop software ontwikkeld wordt is dat eerst de test geschreven wordt, en dan de implementatie. De test zal dus niet werken voordat de implementatie gereed is. Echter, het komt wel eens voor dat mensen naar huis gaan, en hun implementatie niet op tijd geleverd krijgen. De code dient echter (bij voorkeur) wel ingechecked te worden. Echter, als iemand anders dan de volgende dag zijn codebase update, zullen zijn testen falen.
Ik vroeg me daarom af wat jullie ervaring hiermee is, en wat de oplossing is? Niet inchecken bijvoorbeeld, of het niet interesseren dat de testen falen, ze zijn immers toch niet van jou, of iets anders?

Alvast bedankt voor de suggesties,

gr, Erik

[Verwijderd]

Naar mijn idee kun je op het moment dat iets niet compileert of niet door unit tests heen komt beter niet inchecken. Ik vind dat iets pas ingecheckt kan worden op het moment dat het geen fouten, en dus last voor andere programmeurs opleverd.

Als je dit wel doet wordt het gebruik van unit test ook moeilijker. Unit test zijn onder andere handig om bij het integreren van nieuwe functies in een systeem te testen of dit betaande code niet kapot maakt.
Op het moment dat je fouten moet gaan negeren die niet van jouzelf zijn, hoe weet je dan of je net nieuw gemaakte code niet het hele systeem om zeep helpt?

Een ander punt is natuurlijk op welk moment je dan wel mag inchecken. Op het moment dat een unit test niet meer faalt, of op het moment dat het inhoudelijk ook doet wat het moet doen?
Met andere woorden, check je een mock implementatie in, of doe je dit pas bij een echte implementatie?

[Eärendil]

Je zou kunnen overwegen om voor dit soort dingen een aparte branch te starten en die weer te mergen met de hoofd-branch op het moment dat het weer werkt. Zo hou je de hoofd-branch schoon en kan je toch alle code inchecken.

[Woy]

In de nieuwe source-safe die eraan komt zit daarvoor een functie die "Shelving" heet. Dan check je je code niet daadwerkelijk in maar wordt wel weer opgenomen in de source-safe database. Hiermee kan je dus code die nog niet klaar is zeg maar apart zetten zodat het wel in source-safe zit maar nog niet is ingecheckd.

Code moet je pas inchecken op het moment dat je klaar bent met de wijziging die jij aan moest brengen

Bij Test driven development werkt het natuurlijk wel anders. Je maakt eerst een stel lege classes waarvoor je tests gaat schrijven. Als je die incheckt dan failen aan het begin eerst al je tests ( er is namelijk nog niks geimplementeerd. Daarna gaat iemand aan een stukje code werken zodat er een ( of meerdere ) tests wel slagen als diegene klaar is met dat stukje en er niet voor heeft gezorgd dat andere tests weer failen dan kan je het inchecken.

[.oisyn]

bodiam schreef op woensdag 24 augustus 2005 @ 17:19:
De code dient echter (bij voorkeur) wel ingechecked te worden.

Je gaat natuurlijk geen code dat niet werkt of zelfs niet compilet inchecken in je hoofdbranch, als iemand anders dan de volgende dag sync'd zit hij met de gebakken peren omdat jij nog helemaal niet klaar was, wat nogal counterproductief is (zeker als je geen direct contact met je collega's hebt, zoals wij hebben met onze collega's in de verenigde staten). Ik vind de elke dag verplicht inchecken dan ook een beetje een onzinregel, als je zorg is dat er een hdd crasht en je daardoor een aantal dagen werk kwijt bent, kun je ook wel gewoon automatische backups maken.

Als je echter met iets groters bezig bent waar een week of meer tijd in gaat zitten voordat je een werkende update in kunt checken, kun je beter even in een eigen branch gaan werken zodat je wel kapotte code in kunt checken zonder dat iemand daar last van heeft. Aan het eind van je taak integrate je dat gewoon naar de hoofd branch.

of het niet interesseren dat de testen falen, ze zijn immers toch niet van jou

Vind ik overigens ook een beetje raar. Als een test al wel geïmplementeerd is, maar datgene wat er getest moet worden nog niet, dan moet die test ook nog niet uitgevoerd worden. Pas als er een implementatie is waarvan gezegd wordt dat hij zou moeten werken heeft zo'n test pas nut. Als je dan toch per se alle tests uit wil voeren zorg er dan voor dat er een reden opgegeven kan worden waarom de test faalt, zodat je de testresultaten hierop kunt filteren.

[ Voor 21% gewijzigd door .oisyn op 24-08-2005 19:17 ]

[Woy]

.oisyn schreef op woensdag 24 augustus 2005 @ 19:10:
[...]
Vind ik overigens ook een beetje raar. Als een test al wel geïmplementeerd is, maar datgene wat er getest moet worden nog niet, dan moet die test ook nog niet uitgevoerd worden. Pas als er een implementatie is waarvan gezegd wordt dat hij zou moeten werken heeft zo'n test pas nut. Als je dan toch per se alle tests uit wil voeren zorg er dan voor dat er een reden opgegeven kan worden waarom de test faalt, zodat je de testresultaten hierop kunt filteren.

Dat is niet altijd zo. Er zijn wel stromingen in de Test Driven Development die vinden dat je eerst alle testen moet maken die alle requirements testen, zelfs nog voordat er logica is gescreven. Dus aan het begin zullen die testen falen.

Dan wordt je doel met coden om zoveel mogenlijk tests te laten slagen. Als op een gegeven moment alle tests slagen dan is je software "af".
Als je op die manier werkt ga je als er een bug gemeld wordt eerst een test schrijven die die bug weet te herhalen en dus zorg je ervoor dat je test op dat punt faalt. Dan ga je je code weer maken. Door op deze manier te testen weet je zeker dat dezelfde bug later niet nog een keer terug kan komen want die situati is nou opgenomen in je tests.

Zelf vindt ik het wel overdreven om eerst meteen alle tests te maken. Het lijkt me logischer om een deel software te maken en daarbij ongeveer gelijktijdig de tests mee te ontwikkelen. Door het ontwikkelen van de tests denk je er tenslotte ook beter over na welke uitzonderingen er optreden.

[.oisyn]

rwb schreef op woensdag 24 augustus 2005 @ 19:58:
[...]

Dat is niet altijd zo. Er zijn wel stromingen in de Test Driven Development die vinden dat je eerst alle testen moet maken die alle requirements testen, zelfs nog voordat er logica is gescreven. Dus aan het begin zullen die testen falen.

Hmm ok, maar dan zie ik het probleem van de TS eigenlijk niet, aangezien het gros van de tests nog zal falen in het begin van je devcycle.

Zelf vindt ik het wel overdreven om eerst meteen alle tests te maken. Het lijkt me logischer om een deel software te maken en daarbij ongeveer gelijktijdig de tests mee te ontwikkelen. Door het ontwikkelen van de tests denk je er tenslotte ook beter over na welke uitzonderingen er optreden.

Idd, al zou je ook in het begin basis tests kunnen schrijven die simpelweg de globale pre en post conditie van je hele subsysteem testen, en tijdens het implementeren van de logic die tests kunnen verfijnen zodat ze meer de randen aftasten.

Ben overigens niet bekend met "Test Driven Development", er zit in onze codebase sowieso in verhouding maar wat weinig componenten die echt geautomatiseerd getest kunnen worden. De meeste dingen vereisen gewoon user input of -verificatie.

[ Voor 3% gewijzigd door .oisyn op 24-08-2005 20:12 ]

[whoami]

Ik ben het eens met het gros van de mensen die hier gereageerd hebben: code moet je pas inchecken als ze compileert, en alle tests voor die code slagen. (Sidenode: evt niet geimplementeerde stukken code die een test doen falen, kunnen imho ook wel ingechecked worden).

[Verwijderd]

Wij hebben als regel dat je niet compilerende code simpelweg niet incheckt. Als het wel compileert maar de unit test faalt, zal je dat over het algemeen toch inchecken. Er is een server die 's nachts automatisch code uit de source safe db haalt en compileert, en vervolgens alle unit tests draait, zodat er 's ochtends een rapport is dat weergeeft hoe het ermee staat. Verantwoordelijken voor niet-compilerende code worden mee naar buiten genomen en ritueel met zweepslagen tot de orde geroepen .... nou ja, dat laatste in gedachte in ieder geval.

Verder is er natuurlijk zoiets als common sense. Als je aan een module werkt waar anderen van afhankelijk zijn, die het nu wel goed doet, maar waaraan je gaat verbouwen, dan zorg je dat je die versie tijdelijk afsplitst, zodat je anderen niet lastig valt ermee.

[Woy]

Het lijkt me ieder geval logisch inderdaad dat je niet compilerende code niet incheckd. Als iets niet compileerd heb je er simpelweg niets aan. Als je daaraan begint is het inchecken niets meer als een veredeld backup systeem en daar zijn ook wel andere oplossingen voor te bedenken.

[chris]

rwb schreef op donderdag 25 augustus 2005 @ 00:47:
Het lijkt me ieder geval logisch inderdaad dat je niet compilerende code niet incheckd. Als iets niet compileerd heb je er simpelweg niets aan. Als je daaraan begint is het inchecken niets meer als een veredeld backup systeem en daar zijn ook wel andere oplossingen voor te bedenken.

offtopic:
Noem me een mierrenneuker, maar leer alsjeblieft werkwoorden vervoegen.
In tegenwoordige tijd:

ik-vorm: stam
jij/hij/zij-vorm: stam + [b]t[b]

en een voltooid deelwoord kan soms met een d zijn. Maar in jouw geval moet incheckd en compileerd echt met een t.

[Verwijderd]

chris schreef op donderdag 25 augustus 2005 @ 01:30:
[...]

offtopic:
Noem me een mierrenneuker, maar leer alsjeblieft werkwoorden vervoegen.
In tegenwoordige tijd:

ik-vorm: stam
jij/hij/zij-vorm: stam + [b]t[b]

en een voltooid deelwoord kan soms met een d zijn. Maar in jouw geval moet incheckd en compileerd echt met een t.

offtopic:
Wat zijn mierren?

[spone]

Verwijderd schreef op donderdag 25 augustus 2005 @ 01:46:
[...]

offtopic:
Wat zijn mierren?

offtopic:
datgene wat jij nu aan het *-en bent

[Woy]

chris schreef op donderdag 25 augustus 2005 @ 01:30:
[...]

offtopic:
Noem me een mierrenneuker, maar leer alsjeblieft werkwoorden vervoegen.
In tegenwoordige tijd:

ik-vorm: stam
jij/hij/zij-vorm: stam + [b]t[b]

en een voltooid deelwoord kan soms met een d zijn. Maar in jouw geval moet incheckd en compileerd echt met een t.

offtopic:
Helemaal gelijk, ik kwam net uit de kroeg dus lette er daarom niet echt meer op.

[whoami]

Modbreak:

Kunnen we weer ontopic gaan ?
Ff lollen is wel leuk, maar 4 offtopic replies in een topic van 13 replies is wel genoeg, denk je niet ?


En als je iemand's spelling wilt verbeteren, doe dat dan buiten het forum om of in een post die verder on-topic is

[ Voor 28% gewijzigd door .oisyn op 25-08-2005 11:13 ]

[bodiam]

[quote].oisyn schreef op woensdag 24 augustus 2005 @ 20:09:
[...]

Hmm ok, maar dan zie ik het probleem van de TS eigenlijk niet, aangezien het gros van de tests nog zal falen in het begin van je devcycle.
[...]

Mee eens. Als je er voor kiest om al je testen te schrijven voordat je begint met de daadwerkelijke implementatie, is mijn vraag een beetje onzinnig. De testen zullen immers altijd falen totdat de ontwikkeling klaar is. Echter, ik ga niet eerst al mijn testen schrijven, ik schrijf ze soms ervoor, meestal erna, en wellicht vaak niet.

Wellicht dat het niet uitvoeren van testen die nog niet werken een optie is, maar ik zie het niet zo gebeuren. Ik heb een soort van angstig gevoel dat deze testen dan altijd niet uitgevoerd worden, omdat mensen 'vergeten' (of whatever) ze aan te zetten.

De meeste dingen vereisen gewoon user input of -verificatie.

Zijn daar niet juist de (automatische) testen voor bedoeld?

[Jaspertje]

Bij ons is het zo bij de talen die gecompileerd moeten worden dat het pas ingechekt mag worden als het compileert (Geen garantie dat de code an sich ook werkt!) Bij de scripttalen is het zo dat het ook moet werken. Uitteraard kan het voorkomen dat het nog niet helemaal 100% werkt, maar daar zijn testers voor.

[curry684]

Ik hanteer binnen mijn devteams altijd als regel dat je een sourcefile zo snel mogelijk weer vrijgeeft, wat inhoudt dat het compileert en het geen bestaande code breekt. Of de code perfect werkt en af is is voor mij dus secundair, zolang je je team members maar niet onnodig in de weg zit: een niet irreeel risico als je zoals ik met Indiers in andere timezone moet werken. Een file uitgecheckt houden terwijl je naar huis gaat mag alleen met goede reden, en een hele directory uitgecheckt houden terwijl je weg gaat levert je spanking op

[bodiam]

curry684 schreef op vrijdag 26 augustus 2005 @ 10:53:
Ik hanteer binnen mijn devteams altijd als regel dat je een sourcefile zo snel mogelijk weer vrijgeeft, wat inhoudt dat het compileert en het geen bestaande code breekt. Of de code perfect werkt en af is is voor mij dus secundair, zolang je je team members maar niet onnodig in de weg zit: een niet irreeel risico als je zoals ik met Indiers in andere timezone moet werken.

Oncompileerbare code inchecken is zeker niet toegestaan, en het 'eind van de dag inchecken' van code is meer een stok achter de deur dat mensen ook daadwerkelijk code inchecken, en niet week(en) ontwikkelen zonder te CVS-en.

Het grootste nadeel van niet werkende (wel compileerbaar, maar falend van JUnit testen) code vind ik dat het testen van mijn eigen code niet meer lekker gaat. Als ik een JUnit test draai, vind ik het fijn als er iets staat als: 40 test run, 40 succes, 0 failure. En niet 5 failures, omdat iemand bezig is, omdat het eerste wat ik ga doen is het uitzoeken waarom mijn JUnits failen. Misschien moet ik die fouten maar gewoon negeren, dan ben ik van het gezeik af, maar voor mijn gevoel hecht ik veel waarde aan die "magische" 0.

Een file uitgecheckt houden terwijl je naar huis gaat mag alleen met goede reden, en een hele directory uitgecheckt houden terwijl je weg gaat levert je spanking op

VSS ofzo? Iedereen heeft namelijk altijd alles uitgecheckt..
(gewoon interesse, ik ben niet op zoek naar een VSS/CVS discussie!)

[Woy]

bodiam schreef op vrijdag 26 augustus 2005 @ 11:15:
[...]
Het grootste nadeel van niet werkende (wel compileerbaar, maar falend van JUnit testen) code vind ik dat het testen van mijn eigen code niet meer lekker gaat. Als ik een JUnit test draai, vind ik het fijn als er iets staat als: 40 test run, 40 succes, 0 failure. En niet 5 failures, omdat iemand bezig is, omdat het eerste wat ik ga doen is het uitzoeken waarom mijn JUnits failen. Misschien moet ik die fouten maar gewoon negeren, dan ben ik van het gezeik af, maar voor mijn gevoel hecht ik veel waarde aan die "magische" 0.

Wat is het probleem als een test niet werkt? Testen die falen geven gewoon aan dat er nog iets niet klopt aan die code.
Als er een test faalt kijk je gewoon of dat stuk code onder jouw verantwoording valt en of het prioriteit heeft dat het gefixed wordt.
Als alle tests slagen geeft dat aan dat je code wat je op dit moment hebt gewoon goed werkt en dat of je product af is of dat je verder kan gaan met nieuwe stukken code.

Ik zie niet echt in wat het probleem is dat er een aantal testen falen. Je weet dat tijdens het ontwikkelen van een product nog niet alles werkt dus dan is het niet meer dan logisch dat er een aantal testen falen. Dat lijkt me niet echt problematisch.

[curry684]

bodiam schreef op vrijdag 26 augustus 2005 @ 11:15:
[...]

VSS ofzo? Iedereen heeft namelijk altijd alles uitgecheckt..

Uh SourceSafe ja, maar wat bedoel je met 'iedereen heeft altijd alles uitgecheckt'?

Wat betreft de magische 0 ben ik het met rwb eens, die is pas interessant zodra je richting release komt

[Salandur]

in mijn ogen zijn unit testen bedoelt om bij de release van een programma aan te geven dat het goed werkt. Als een test op dat moment faalt kan je je software niet vrijgeven. Dus je kan best een compileerbaar bestand inchecken als de bijbehoordende testen falen, hoewel je dat natuurlijk liever voorkomt. Als je stelt dat je pas iets in mag checken als alle testen ok geven ben je verkeerd bezig, want dat betekend dat iedereen eerst zijn eigen stukkie ontwikkeld en pas vlak voor de release alles ingechecked wordt, immers dan pas kunnen alle testen goed draaien.

[Verwijderd]

Pas committen als de test passed. In een tracker geef je aan dat met een bepaald onderdeel bezig bent.

[.oisyn]

curry684 schreef op vrijdag 26 augustus 2005 @ 10:53:
Ik hanteer binnen mijn devteams altijd als regel dat je een sourcefile zo snel mogelijk weer vrijgeeft, wat inhoudt dat het compileert en het geen bestaande code breekt. Of de code perfect werkt en af is is voor mij dus secundair, zolang je je team members maar niet onnodig in de weg zit: een niet irreeel risico als je zoals ik met Indiers in andere timezone moet werken. Een file uitgecheckt houden terwijl je naar huis gaat mag alleen met goede reden, en een hele directory uitgecheckt houden terwijl je weg gaat levert je spanking op

Ik vind dit maar een rare regel eigenlijk. Wat boeit het of iemand een file uitgechecked houdt? Oh wacht, ja, visual sourcesafe, right, baggerproduct met buggy merges . Wij zitten hier in eenzelfde situatie (collega's in de VS dus ook een andere timezone), maar files uitgecheckt houden is hier echt geen probleem. Wij gebruiken perforce, en als je submit terwijl er in de tussentijd al een nieuwere versie van je file is gekomen moet je gaan mergen. Over het algemeen beïnvloeden de twee changes elkaar voor geen meter en maakt het dus weinig uit, maar soms heb je conflicts en zul je even met de hand moeten mergen (perforce heeft daar een mooie tool voor) en testen of het na afloop nog allemaal naar behoren werkt. En dan check je in.

Daarnaast, als iedereen continu in dezelfde sourcefiles werkt komt het over alsof de verantwoordelijkheden van de werknemers niet voldoende zijn afgesplitst.

bodiam schreef op vrijdag 26 augustus 2005 @ 11:15:
VSS ofzo? Iedereen heeft namelijk altijd alles uitgecheckt..

CVS en Subversion werken zo idd, met pakketten als perforce en sourcesafe check je uit om te mogen editten. Zitten zowel voordelen als nadelen aan om ze uitgecheckt te houden. Het voordeel is dat je ook goed je werk kunt doen als de sourcecontrol server down is of er is geen mogelijkheid tot verbinden (laptop in de trein oid). Het nadeel is dat je niet kunt zien wie er allemaal met een file bezig is. Persoonlijk vind ik dat laatste argument sterker wegen, zeker als je toch al op een vaste werkplek zit.

[Woy]

.oisyn schreef op vrijdag 26 augustus 2005 @ 12:14:
[...]
wacht, ja, visual sourcesafe, right, baggerproduct met buggy merges .

Iets wat trouwens in de Nieuwe VSS die met vs.net 2005 meekomt wel sterk verbeterd is ( Mag ook eindelijk wel eens )