ProgrammeringsBaren! Småprat, om det du elsker!

[torbjørn marø]

Jeg har aldri hatt tid til å lære meg testdrevet utvikling ordentlig og akter heller ikke å gjøre det.

På den tiden du har brukt på denne tråden her hadde du rukket både å bli ganske god i TDD og erfare at teknikken har langt flere fordeler enn at du står igjen med et sett med automatiserte regresjonstester til slutt.

 

Kall meg gjerne religiøs, men jeg er i alle fall av den oppfatning at TDD er det nærmeste vi kommer en Silver Bullet i programmeringsverden. Antall utviklere som har oppdaget dette er sterkt voksende, og mentorer som uncle Bob går sterkt ut og sier at det ikke finnes noen grunn til å la være å gjøre det. At det rett og slett uforsvarlig å ikke gjøre det!

 

TDD har, som mange har påpekt før meg, et litt uheldig navn. Det handler nemlig ikke om testing. Også derfor andre har kommet med alternative navn som f.eks. Behaviour Driven Development.

 

Poenget er at teknikken fokuserer både deg og koden din.

Den gjør koden fleksibel og enkel å modifisere.

Den gjør kodens interface renere og lettere å jobbe med.

Den gjør deg trygg på å gjøre endringer.

Den gjør at du bruker mindre hjernekapasitet på å forstå/huske hva du og andre har gjort, og kan bruke mer på å planlegge fremover.

Du kan eksperimentere mer.

Den kan la deg komme opp med optimale algoritmer på problemer du ikke selv forstår eller kan løsningen på kun ved slavisk å følge enkle steg.

Den forteller deg når du er ferdig.

Og så fungerer testene som dokumentasjon for andre utviklere.

Eller til og med som en spec (finnes f.eks. programmeringsspråk hvor eneste offisielle spesifikasjonen er et sett med tester).

 

hvor mange unit-tester må feile før dette er et faktum? De aller fleste, men det gjør de ikke. De fleste unit-tester går fint igjennom.

Alle unit-tester feiler når du gjør TDD - for koden de tester finnes ikke enda.

 

Får man det inn med morsmelken vet ikke jeg om det blir en tvangstrøye eller som den første slurken du drikker fra bekken.

Jeg begynte seriøst med TDD for ca 3 år siden. I perioden før det slet jeg med å se hvordan det kunne spare meg tid, men hadde tro på at det kunne øke kvaliteten. Det tok en stund å bli god, men nå er jeg mer enn overbevist om at det er til stor hjelp, at jeg er en mye bedre utvikler på grunn av det, og jeg kunne aldri tenke meg å være foruten. Jeg tror rett og slett ikke det er mulig å gå tilbake.

 

Selvfølgelig er det tøft å være en cowboy, å bare spre om seg med kode man ikke kan bevise med et tastetrykk at virker. Det er kult å holde et fullstendig design i hodet på en gang, å drømme i algoritmer. Men hjernen er begrenset - fra Code Complete (min oversettelse):

 

Dine personlige karaktertrekk har direkte innvirkning på din evne til å programmere. Karaktertrekkene som betyr mest er ydmykhet, nysgjerrighet, intellektuell ærlighet, kreativitet, disiplin og opplyst latskap. Overraskende nok gjør ting som rå intelligens, erfaring, ståpåvilje og mot like mye skade som nytte når det kommer til programmering.

 

Så ikke forsøk noe nytt! Og for all del ikke begynn med TDD, for du kan komme til å bli hekta!

Endret 30. august 2011 av torbjørn marø

[torbjørn marø]

Det som dog slår meg med mange av metodikkene (XP, TDD osv) er lansert av folk som har en agenda - de selger kurs og bøker som beskriver metodikken ...

Det er ikke gitt at det var agendaen som kom først. Agile/Smidig som konsept oppstod blant en gjeng med dyktige og erfarne programmerere som en motreaksjon mot stive og formelle prosjekter som ikke klarte å levere. De samlet sammen sine egne erfaringer om hva som fungerte for dem, og dette ble til XP, SCRUM osv.

 

Jeg synes det er flott at gamlekara er villige til å reise rundt og øse av sin kunnskap. I noen tilfeller har det derimot gått for langt, som med SCRUM-sertifiseringskursene, og agile-konsulent-markedet som har blomstret opp. Er med på den.

 

TDD er forresten ikke noe nytt, og har blitt praktisert i alle fall siden 70-tallet. Det er bare navnet som er nytt.., og utbredelsen.

 

Selvsagt finnes det mange veier til mål, og man blir etterhvert god på det man praktiserer. Men selv om mye kan være bra så kan det også tenkes at noe er best?!

Endret 30. august 2011 av torbjørn marø

[tomsi42]

Det er ikke gitt at det var agendaen som kom først. Agile/Smidig som konsept oppstod blant en gjeng med dyktige og erfarne programmerere som en motreaksjon mot stive og formelle prosjekter som ikke klarte å levere. De samlet sammen sine egne erfaringer om hva som fungerte for dem, og dette ble til XP, SCRUM osv.

Tja. At en agile/smitid tilnærming til utvikling er fornutig, det kan jeg være enig i. Men mange av disse guruene har brukt metodikken på et ( eller muligens to prosjekt) før de har sett lyset. Og deretter er det fullt øs på markedsføringen.

 

Selvsagt finnes det mange veier til mål, og man blir etterhvert god på det man praktiserer. Men selv om mye kan være bra så kan det også tenkes at noe er best?!

Jeg har mer tro på en pragmatisk tilnærming der man sørger for een god grunnkunnskap på forskjellige teknikker og metodikker og tilpasser de til det virkelige liv og de problemene som skal løses. Det som er best i en situasjon kan godt være veldig feil i en annen.

[torbjørn marø]

Det som er best i en situasjon kan godt være veldig feil i en annen.

På generell basis kan jeg ikke si noe imot det. Som jeg sa finnes det ingen silver bullet, bare en ting som jeg føler er veldig nære ved å være det.

Endret 30. august 2011 av torbjørn marø

[torbjørn marø]

Jeg har et forslag! Hvis du ikke er fullstendig enig med meg.., har du en time til overs? Da vil jeg anbefale deg å ta en titt på Robert C. Martins Keynote fra InfoQ London 2010: Bad Code, Craftsmanship, Engineering and Certification. Den er en god oppsummering av hva jeg snakker om, og å høre på Bob er langt mere underholdende enn å lese mitt "utenomsnakk".

 

http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code

 

Dere kan med fordel starte 7 minutter inn i presentasjonen. Før det snakker han først om The Big Bang, og viser videoen Bad Code, som ikke er gjengitt så bra i filmingen av presentasjonen. Klikk gjerne på linken å se den først om du har 3 minutter ekstra.

 

Så kan vi diskutere påstandene hans videre derfra!?!

[GeirGrusom]

Hehe ville nevne en type bug som jeg hater... holdt på med det i nesten hele dag.

 

Sitter med en mikrokontoller vi har utviklet for å styre en servo-motorer. Har slitt med at kommunikasjonen ikke har fungert i dag, og har gjennomsøkt hele systemet med oscilloskop og multimeter. Alt så ut til å stemme. Koblet den så til JTAG for å se om det funket, og OpenOCD koblet til med en gang. Prøvde å koble GDB til for å laste inn ny firmware, men det funket derimot ikke (GDB fikk masse tullenull)

Plutselig forsvinner problemet. Nå funker alt som det skal. Jeg gjorde ingenting :S

[tomsi42]

Kall meg gjerne religiøs, men jeg er i alle fall av den oppfatning at TDD er det nærmeste vi kommer en Silver Bullet i programmeringsverden. Antall utviklere som har oppdaget dette er sterkt voksende, og mentorer som uncle Bob går sterkt ut og sier at det ikke finnes noen grunn til å la være å gjøre det. At det rett og slett uforsvarlig å ikke gjøre det!

Det er jo mulig at du har blitt religiøs og har funnet din religion

 

TDD har, som mange har påpekt før meg, et litt uheldig navn. Det handler nemlig ikke om testing. Også derfor andre har kommet med alternative navn som f.eks. Behaviour Driven Development.

Dette ser ut som en interessant videreutvikling. Takk for info.

 

Alle unit-tester feiler når du gjør TDD - for koden de tester finnes ikke enda.

Problemet er hva som skjer etter at testen virker. Er du da sikker på at testen vil feile i fremtiden når noe blir endret? Eller er testen for grunn?

 

Men hjernen er begrenset - fra Code Complete (min oversettelse):

Kan si meg enig i det sitatet. Har sett mye cowboy kode som er umulig å fikse i ettertid.

 

Så ikke forsøk noe nytt! Og for all del ikke begynn med TDD, for du kan komme til å bli hekta!

Har du noen fler linker rundt BDD og TDD? Det jeg kunne tenke meg, er noen linker på muighetene å begynne å bruke teknikkene på eksisterende prosjekter.

[torbjørn marø]

Har du noen fler linker rundt BDD og TDD? Det jeg kunne tenke meg, er noen linker på muighetene å begynne å bruke teknikkene på eksisterende prosjekter.

For å få kontroll på såkalt legacy code (basically kode uten tester) er mannen man bør høre på Michael C. Feathers. Boken hans, Working Effectively With Legacy Code (min review her), gir deg praktiske teknikke for å gjøre eksisterende kode testbar.

 

Ellers er det ikke så vanskelig å finne mye bra om BDD og TDD, men har ingen hovedkilder. Et annet søkebegrep er "context specification".

Endret 30. august 2011 av torbjørn marø

[Matsemann]

Av nysgjerrighet, hva har du gjort innenfor programmering, tomsi? Ikke ment for å brukes mot deg, bare av nysgjerrighet. Tenker på utdanning, jobb osv. Vet nemlig hva mange andre her i tråden driver med til daglig, men for meg er du bare en "fotofyr".

 

Selvsagt finnes det mange veier til mål, og man blir etterhvert god på det man praktiserer. Men selv om mye kan være bra så kan det også tenkes at noe er best?!

Har vært på en del bedriftpresentasjoner med middag o.l. med representanter fra bedrifter. En gjenganger er at mange av teamene i konsulentbedriftene liker SCRUM.

 

Men finnes nok ingen som er best til alle formål. Avhenger jo helt av type prosjekt, antall involverte osv.

[tomsi42]

Av nysgjerrighet, hva har du gjort innenfor programmering, tomsi? Ikke ment for å brukes mot deg, bare av nysgjerrighet. Tenker på utdanning, jobb osv. Vet nemlig hva mange andre her i tråden driver med til daglig, men for meg er du bare en "fotofyr".

Jeg er mest en halvstudert røver innen faget - der utdannelsen har mest basert på selvstudier og kurs i regi av jobben.

 

Grunnutdannelsen er fra marinen tidlig på 80-tallet (radar-tekniker); der vi lærte basic, assembler og noe fortran. Jobbet deretter som servicetekniker ved Prime Computers mens jeg lærte meg Pascal og C på fritiden. Det ble også en del med script programmering som en del av jobben. På begynnelsen 90-tallet gikk jeg på et års AMO kurs (C/nettverk). Deretter har jeg mest jobbet som programmerer innenfor en del språk (C, Delphi, Navision/Pascal, perl, python, Java, PL/SQL og tcl). Man har i tillegg en del erfaring med unix, enkelt nettverksoppsett osv. Er som en potet med andre ord ...

 

Har vært på en del bedriftpresentasjoner med middag o.l. med representanter fra bedrifter. En gjenganger er at mange av teamene i konsulentbedriftene liker SCRUM.

Scrum virker - det bruker vi selv. Men det er mest en metodikk for å søge for at prosjektene fullføres i riktig tid.

Endret 30. august 2011 av tomsi42

[Matsemann]

Ah, spennende. Vært med i gamet lenge, altså.

[tomsi42]

For å få kontroll på såkalt legacy code (basically kode uten tester) er mannen man bør høre på Michael C. Feathers. Boken hans, Working Effectively With Legacy Code (min review her), gir deg praktiske teknikke for å gjøre eksisterende kode testbar.

 

Ellers er det ikke så vanskelig å finne mye bra om BDD og TDD, men har ingen hovedkilder. Et annet søkebegrep er "context specification".

Takk for bokforslag - den skal nok bestilles. Og google skal nok få kjørt seg i tiden fremover

 

Ah, spennende. Vært med i gamet lenge, altså.

Jepp; nesten lenge nok til å gå lei

Endret 30. august 2011 av tomsi42

[snippsat]

En god video om BDD.

Liker godt godt tankegang rund BDD.

Jeg prøver stadig og lære meg mer om TDD og ser helt klart fordelene,

men ser også at dette kan gjøres feil.

Som det påpekes i videoen at TDD brukes nok av mange på en feil måte.

 

Viss man gjør TDD bra så er man inne på BDD tankegangen,man ser på spesifikasjoner og adferd og går litt bort fra ordet test som erstattes med spesifikasjoner/adferd.

Endret 30. august 2011 av SNIPPSAT

[Johan]

Jeg har brukt TDD av og til, og det har stort sett fungert veldig bra. Jeg prøver stort sett å holde meg til det, men i det siste har jeg drevet en del med et prosjekt hvor testene kan være vanskeligere å lage enn å implementere selve programmet. Ble da litt vanskeligere å luke ut noen bugs, og noen andre bugs fikk stå lenge før de ble oppdaget og rettet. Tilslutt ble jeg vel egentlig nødt til å lage regressjonstester allikevel, så jeg kunne vel egentlig ha starta hele greia med TDD fra bunn av.

 

Jeg vet ikke om TDD er noe sliver bullet, men et fint sett med tester er en veldig god ressurs, uansett hva du skal gjøre med programmet, enten det er å sjekke for regressjoner eller å bruke dem som utgangspunkt for å se hvordan koden brukes/kjøres.

[torbjørn marø]

Har du noen fler linker rundt BDD og TDD? Det jeg kunne tenke meg, er noen linker på muighetene å begynne å bruke teknikkene på eksisterende prosjekter.

Jeg kunne jo ha trukket frem noen av mine egne ressurser også forresten.

 

Utenfra-og-inn programmering - litt om filosofien og teknikkene bak BDD. En grei intro til konseptene.

 

Avhengighetsisolering (a.k.a. mocking) i .net - mocking er en viktig teknikk i TDD/BDD.

 

TDD og Mocking i praksis - en laaaang blogpost/tutorial som demonstrerer TDD i C#.

 

Bowlin Kata - En video hvor du får se meg implementere scoring-algoritme for bowling. Jeg utvikler i Clojure, men en interessert utvikler klarer nok å følge med, selv om syntaksen er ukjent.

 

Kodekata: Romertall - En blogpost som forsøker å vise hvordan TDD hjelper meg å løse integer-til-romertall-konvertering. Inneholder både Clojure og C#.

 

En agurktest - en blogpost om Cucumber, et BDD-verktøy laget i Ruby (men som også brukes av mange C# og Java-utviklere). Specflow er et rent .NET-alternativ (google på egenhånd).

 

Mm... Håper noe av dette er av interesse!

[tomsi42]

Mm... Håper noe av dette er av interesse!

Direkte uinteressant var det ikke Takk for linkene.

[tomsi42]

Driver å lære meg tcl om dagen (Don't ask). Nå er ikke akkurat Tcl kjent for å være sterkt typet, så jeg ble litt overrasket over denne:

 

$ tclsh
% set value "true"
true
% if {$value} { puts "Oh, yeah!"} else { puts "Bummer" }
Oh, yeah!
% set value "blomkål"
blomkål
% if {$value} { puts "Oh, yeah!"} else { puts "Bummer" }
expected boolean value but got "blomkål"

 

Vil nå påstå at boolean er en distinkt data type og ikke en string ...

[torbjørn marø]

Driver å lære meg tcl om dagen (Don't ask).

Veldig interessert i å høre om du finner noen spesielle styrker ved tcl som du kan dele med oss.

[tomsi42]

Veldig interessert i å høre om du finner noen spesielle styrker ved tcl som du kan dele med oss.

Og jeg er veldig interessert i å finne noen spesielle styrker ved tcl overhode

 

Neida, tcl største styrke er et det er veldig enkelt script språk å lære. Jeg ser på tcl som et alternativ til shell script og perl; en del kraftigere enn førstnevnte, og klart mer lesbart enn sistnevnte. Synes jeg ihvertfall.

 

Tcl er et relativt gammlet språk, og mangler mye i forhold til nyere språk som python og ruby. Objektorientering f.eks.

 

Syntax er noe sært da språket kun skjønner en ting: kommandoer - if og løkker er også implementert som kommandoer ...

beregninger gjøres med kommandoen expr: set var [expr 2 * 3] istedet for var = 2 * 3 ...

 

En ting som er veldig enkelt i tcl er nettverksprogrammering.

Endret 3. september 2011 av tomsi42

[torbjørn marø]

expr: set var [expr 2 * 3] istedet for var = 2 * 3 ...

Jeg ser Lisp-innflytelse

Endret 3. september 2011 av torbjørn marø