Testdreven utvikling

[nwinger]

Hva er deres synspunkter? For min del gikk det opp et lys da jeg prøvde dette for første gang. (Utrolig at universitetet ikke lærer meg dette!)

 

Skriv en test, og navngi den på en forståelig måte.

Skriv kode til testen kjører på grønt.

 

Kan ikke tenke meg en mer genial metode å kode på!

[☀ ❄]

Hva er deres synspunkter? For min del gikk det opp et lys da jeg prøvde dette for første gang. (Utrolig at universitetet ikke lærer meg dette!)

 

Skriv en test, og navngi den på en forståelig måte.

Skriv kode til testen kjører på grønt.

 

Kan ikke tenke meg en mer genial metode å kode på!

 

Så lenge man følger god testpraksis og er litt pragmatisk i gjennomførelsen er jeg helt enig: TDD er genialt. Man må passe på å holde det proporsjonalt til koden - altså ikke bruke masse tid på å sette opp et fancy testrammeverk før det egentlig er nødvendig. Utover det har jeg egentlig ingenting å utsette på TDD, og TDD er essensielt for å kunne gjøre trygg refaktorering i større kodebaser, osv. Det er en grunn til at TDD er veldig utbredt i arbeidslivet

 

At universiteter ikke lærer bort dette skikkelig er ikke så rart. De ligger stort sett 10-20 år bak næringslivet, og foreleserne på de fleste universiteter har ikke kodet noe skikkelig selv uansett: De er professorer, ikke utviklere.

[torbjørn marø]

TDD FTW! Denne måter å jobbe på har bare så mange fordeler at det som regel bare er dumt å ikke jobbe sånn. Eller som Uncle Bob sier (tatt fra minne): "Jurien er tilbake: TDD virker! Jeg vil faktisk gå så langt som å si at du ikke er en profesjonell utvikler om du ikke bruker TDD."

 

Er likevel ikke alltid jeg bruker det, men angrer som regel

[rozon]

Pex og Moles... Noen som har jobbet med disse to i forbindelse med TDD?

 

Moles har jeg brukt bittelitt, og synes det er ganske greit når det virker som jeg forventer.

 

Pex har jeg litt mer utfordring med... Hva er Pex egentlig?

[NevroMance]

Har ikke sett noe på Pex og Moles, men ett par ting jeg stusser litt over, da spessielt over Pex:

 

Etter som jeg forsto, så lager Pex testkode for deg. Stemmer dette? I tilfelle har jo ikke Pex peiling på hvordan metodene dine er ment å fungere, og dermed ikke om metoden du har skrevet som den skal teste faktisk er riktig. Det bryter jo også med TDD ved at du først må skrive en korrekt metode (Sikker på at metoden din er bug fri?) før du får generert en test av den. TDD går jo ut på at du definerer hva koden din skal gjøre, og dokumenterer dette i en test før du begynner å skrive koden din. Altså det motsatte av hva Pex gjør.

 

Moles ser jeg dog noen fordeler med, da du kan stubbe ut deler av koden. Men på den andre siden kan man vel se to ganger på designet sitt hvis en sitter og må stubbe ut store deler av koden for å gjøre den testbar. F. eks. ved å bruke interfaces og sende inn istedenfor å bruke ting direkte. Dermed kan du implementere en stub av interfaces for testene dine. Noen ganger er selvsagt dette vanskelig, men i de fleste tilfellene vil nok en nøye gjennomgang av designet fjerne mange av disse problemene som Moles løser.

[dahuff]

Å jobbe med tester lærte meg i alle fall hvorfor loose coupling er viktig. Skjønner heller ikke hvorfor jeg ikke lærte dette på skolen.

[rozon]

Har ikke sett noe på Pex og Moles, men ett par ting jeg stusser litt over, da spessielt over Pex:

 

Etter som jeg forsto, så lager Pex testkode for deg. Stemmer dette? [....]. Altså det motsatte av hva Pex gjør.

 

Moles ser jeg dog noen fordeler med, da du kan stubbe ut deler av koden. Men på den andre siden kan man vel se to ganger på designet sitt hvis en sitter og må stubbe ut store deler av koden for å gjøre den testbar. F. eks. ved å bruke interfaces og sende inn istedenfor å bruke ting direkte. Dermed kan du implementere en stub av interfaces for testene dine. Noen ganger er selvsagt dette vanskelig, men i de fleste tilfellene vil nok en nøye gjennomgang av designet fjerne mange av disse problemene som Moles løser.

 

Mesteparten av koden som eksisterer er vel ikke TDD, og da kan Pex hjelpe deg såvidt jeg har forstått. Testing er mer enn bare TDD også...

 

Jeg bruker Moles til å stubbe databaseoppslag og andre ting som jeg ønsker å teste, og trenger prediktable output fra. Eksempelvis en test for å avgjøre som avhenger av dato så vil jeg stubbe DateTime slik at jeg får en kjent dato hver gang testen kjøres. Fordelen med Moles er nettopp at du kun stubber det du bruker, og det er bra for DRY prinsippet...

 

Ja, du kan nok designe bort behovet for Moles, men... Du må nesten se om det er verd det for prosjektet du er på liksom. Stubber er somregel en linje eller 4...

 

dahuff: Hele prinsippet med TDD er loose coupling.

[NevroMance]

Helt enig i at Pex kan hjelpe i slike tilfeller, altså ved eksisterende kode skrevet uten å tenke på testing, dette er da gjerne eldre kode. Også enig i at Testing er mye mer enn bare TDD. Grunnen til min kommentar kom fra topic, som jo er TDD.

 

Hvis planen er å drive med testdreven utvikling burde applikasjonen designes ut i fra dette. Det vil si å f. eks. skrive en wrapper rundt databasen med ett kjent interface, slik at du enkelt kan stubbe ut behovet for databasen uten hjelp av ting som Moles. Det gjør at du også er helt uavhengig av eksterne dependencies i unit testene dine, og kan være 99% sikker på at i det minste den koden som tests fungerer as intended. Det er hverfall mitt syn på hvordan TDD burde gjøres, skriv biblioteker med loose coupling slik at du enkelt, og uten eksterne dependencies, kan teste deler/units av koden din.

 

Selvsagt er ikke det mulig hvis TDD ikke er brukt, og en må derfor bruke ting som Pax som hjelpeverktøy. Men da er det ikke lenger testdreven utvikling, som er topic.

[GeirGrusom]

TDD FTW! Denne måter å jobbe på har bare så mange fordeler at det som regel bare er dumt å ikke jobbe sånn. Eller som Uncle Bob sier (tatt fra minne): "Jurien er tilbake: TDD virker! Jeg vil faktisk gå så langt som å si at du ikke er en profesjonell utvikler om du ikke bruker TDD."

 

Er likevel ikke alltid jeg bruker det, men angrer som regel

Det er en ganske lur måte å jobbe på ja. Men definisjonen av "profesjonell" har ikke under noen omstendigheter noe som helst med hvordan du jobber å gjøre. Du kan arbeide Ad-Hoc med LOGO og likevel kalle deg profesjonell hvis det er det du lever av.

 

Testdreven utvikling er dog ganske essensielt, men jeg vil si dette er bare et aspekt som kreves av god kode. Du må også skrive kode som er enkelt å teste.

Endret 4. januar 2012 av GeirGrusom

[rozon]

Hvis planen er å drive med testdreven utvikling burde applikasjonen designes ut i fra dette. Det vil si å f. eks. skrive en wrapper rundt databasen med ett kjent interface, slik at du enkelt kan stubbe ut behovet for databasen uten hjelp av ting som Moles. Det gjør at du også er helt uavhengig av eksterne dependencies i unit testene dine, og kan være 99% sikker på at i det minste den koden som tests fungerer as intended. Det er hverfall mitt syn på hvordan TDD burde gjøres, skriv biblioteker med loose coupling slik at du enkelt, og uten eksterne dependencies, kan teste deler/units av koden din.

 

Jeg ser ikke hvordan det du foreslår er forskjellig fra å stubbe? Du refererer til moles for å få en instance av et interface, og stubber de metodene/properties som koden du tester bruker.

 

Hvodan tester du f.eks. fil tilgang?

[torbjørn marø]

Det er en ganske lur måte å jobbe på ja. Men definisjonen av "profesjonell" har ikke under noen omstendigheter noe som helst med hvordan du jobber å gjøre. Du kan arbeide Ad-Hoc med LOGO og likevel kalle deg profesjonell hvis det er det du lever av.

Profesjonell har mer enn én betydning vet du. På den ene siden betyr det rett og slett å tjene penger på det du gjør - som du påpeker - men på den andre siden betyr det å være en del av en profesjon, å følge profesjonens regler og normer, å følge en etikk, å ha en viss standard. Dette er vel de man som regel mener når man sier profesjonell, er det ikke? Det er i alle fall hva jeg mener.

 

Testdreven utvikling er dog ganske essensielt, men jeg vil si dette er bare et aspekt som kreves av god kode. Du må også skrive kode som er enkelt å teste.

Om du utvikler koden din med TDD så er koden nesten automatisk enkel å teste. Det er litt av poenget. Det går selvsagt an å skrive lite testbar kode også, men siden du skriver testen først så er den i alle fall testbar, selv om koden er "vanskelig".

 

Dette gjelder selvsagt kun om man holder tilnærmet lik 100% test coverage.

 

Jeg er altså veldig enig i at TDD kun er et aspekt, men at kode også skal være enkel å teste var et heller uheldig eksempel på et "annet aspekt". Du kunne for eksempel i stedet ha sagt at kode skal være enkel å forstå, noe TDD ikke automatisk fører til (selv om det også hjelper, siden testene blir en slags dokumentasjon). Eller at kode bør være så enkel som mulig (TDD gir ofte svært enkle grensesnitt, men ikke nødvendigvis funksjoner med lav kompleksitet).