Det er snart et år siden Dan North var i Bergen og snakket om Behaviour-Driven Development (BDD) – et besøk jeg bl.a. dokumenterte i the Contiki Strip #5. Det var et utrolig inspirerende møte, og Given-When-Then spesifikasjonformatet var noe vi prøvde å jobbe med i tiden etterpå. Men siden vi ikke hadde kommet orntlig igang med å skrive enhetstester, og var langt fra å praktisere TDD, glemte vi det raskt ut, og alt forble ved det gamle.

Nå som jeg har jobbet mer med testdreven utvikling er det på tide å ta dette opp igjen. Jeg vil derfor presentere hvordan man kan gå fra “vanlige” unit-tester til å implementere kjørbare spesifikasjoner (the BDD way), og snakke litt om hvilke fordeler dette gir oss.

Ta f.eks. denne enhetstesten, hentet fra Robert C. Martins bok Agile Principles, Patterns, and Practices in C#:

Denne koden har utstract bruk av COMMAND pattern. Testen oppretter først en Employee i databasen (line 5-7), og bekrefter at den ble opprettet (line 9-10). Deretter sender den en slette-komando (linje 11-12) og verifiserer at den nå ikke finnes i databasen lengre (linje 14-15). En helt normal enhetstest etter min mening.

Den uttrykker derimot ikke så mye om intensjonen bak testen – man må lese koden for å forstå hva som skjer, og strukturen er helt og holdent opp til utvikleren. En bedre måte å gjøre dette på er å sette opp et Given-When-Then-senario: Gitt at vi har en kunde, Når vi ber om å få den slettet, Så finnes den ikke lengre i databasen.

Implementert vha. TinyBDD, et rammeverkt for å lage BDD-spesifikasjoner under utvikling av Gjøran Hansen, forvandles enhetstesten til noe sånn som dette:

Om du ikke er vandt med lambda-uttrykk i C# er dette sikkert ganske gresk, men gi det en sjanse likevel. I linje 6 opprettes et nytt senarie. Så på linje 9 sier vi at hvis (Given) en bestemt Employee existerer, og (på linje 12) han finnes i databasen, når (When) man da eksekverer en slette-kommando (linje 15), så (Then) vil Employee’en ikke lenger finnes i basen (linje 18).

Lambda-uttrykkene på linje 10, 13, 16 og 19 utfører og/eller tester det vi har spesifisert i kallene til Given, When og Then. Og sammenligner du med den originale testen så ser du at de egentlig gjør akkurat det samme.

Forskjellen er at BDD-spesifikasjonen beskriver/dokumenterer i klartekst hva situasjonen er og hvilken adferd vi er ute etter. Og spesifikasjonen er så nær koden at det ikke vil være noe problem å holde dem og koden synkronisert om den skulle endres. Den er relativt oversiktelig, og følger et fast mønster.

Og den virkelige gevinsten oppdager du når du innser at disse spesifikasjonene kan skrives av eller i sammarbeid med testere, product owners og til og med kunden selv. Spranget fra kundens eller produktets krav til selve koden blir minimal. Utvikleren og kunden kan f.eks. sitte sammen og skrive spesifikasjonen rett inn i en .cs-fil.

Når spesifikasjonene er definert kan man så kjøre dem underveis i prosjektet, og ta ut rapporter som i klartekst beskriver senariene, og hvilke av dem som er ferdig implementert, hvilke som gjenstår, og eventuelt hvilke som feiler (TinyBDD støtter ikke dette enda såvidt meg bekjent).

BDD er mye mer enn det jeg har vist her. For en praktisk introduksjon til et annet BDD rammeverk som heter MSpec anbefaler jeg at du tar en titt på Rob Conery’s screencast om BDD – meget inspirerende. Og for mer informasjon om BDD generelt er behaviour-driven.org en bra ressurs. Det har vært mye forvirring rundt testdreven utvikling, og BDD gir en litt annen vinkling på problemet, og et sterkere fokus på adferd, noe som vil kunne øke kvaliteten på programvaren du produserer.

Knagger: BDD, Contiki, Dan North, TDD

Det er en stund siden sist, men nå er ventetiden over, og jeg kan presentere The Contiki Strip #9.

Og kanskje blir det også den siste! For til sommeren begynner jeg jo i ny jobb. Det vil sikkert inspirere meg til å lage flere striper som illustrerer livet som .net-utvikler, men da må i alle fall navnet endres. Forslag?

Klikk her for å lese stripe nummer 9, som handler om testdreven utvikling – inspirert av Kent Becks Keynote på RailsConf 2008 (om jeg ikke husker helt feil).

Crowdsourcing har vært et hot begrep lenge, men det er først nå i det siste at vi virkelig har begynt å se mange bedrifter etablere seg basert på denne modellen.

Prinsippet er å distribuere problemløsing og produksjon; en oppgave kringkastes til stor gruppe ukjente problemløsere – amatører og frivillige, eller gjerne også profesjonelle. Enkeltpersonene i denne gruppen, the crowd, leverer hver sin løsning. Gruppen kan også brukes til å stemme frem de beste løsningene. Disse blir så levert til oppdragsgiveren, the crowdsourcer, og den/de som vant blir kompansert – enten med penger, en pris, kudos, eller annen form for belønning.

Fordelene ved crowdsourcing kan være at problemer kan løses raskt, og til en relativt lav pris pga. stor konkurranse. Man betaler kun for resultater, og som oppdragsgiver kan man utnytte talentet til mange flere personer enn man tradisjonelt sett kan ansette selv.

Det finnes som oftest tre ulike parter innenfor crowdsourcing, illustrert i tegningen over, og alle posisjonene i modellen er interessante. Som profesjonell utvikler kan jeg utnytte crowds til å levere verdi for meg på en kostnadseffektiv måte. Som et individ med kunnskaper og fritid kan jeg også bli medlem av et crowd community, og kanskje tjene litt penger på småoppdrag som distribueres til alle medlemmene. Og som en person interessert i inovasjon og nettverksbygging høres det utrolig spennende ut å fasilitere crowdsourcing, og å kunne høste en fortjeneste på å formidle oppdrag.

Den siste tiden har jeg blitt oppmerksom på flere, nystartede firmaer som tilbyr softwaretesting basert på crowdsourcing. Her er noen tjenester man ikke bør overse i disse trange tider:

Testcrowd 1: uTest
uTest gir deg et virtuelt QA team når du trenger det. Nettverket består for tiden av over 16 tusen testere. Du gjør tilgjengelig det som skal testes, f.eks. linken til en testsite, og beskriver gjerne hva som skal testes og eventuelt hvordan. Du betaler kun for bugs som blir funnet (etter at du har kontrollert dem), og du kan også lage en liste med kjente feil, slik at du ikke trenger å betale for ting du vet om på forhånd.

Testerne bygger opp en kvalitets-score, og som oppdragsgiver kan du spesifisere hvilken type testere du ønsker, hvor mange, hvor lenge de skal teste, osv. Startup Success Podcast #22 går i dybden på uTest, og diskuterer også hvordan man bygger et crowd community. Meget insteressant.

Testcrowd 2: UserTesting
Dette nettverket har spesialisert seg på usability testing. Dette er en form for testing som ofte er vanskelig å få til selv, og som normalt koster mye tid og penger om det skal gjøres skikkelig. For 29 dollar tilbyr UserTesting en video av en tester som bruker websiten din mens han forteller hva han opplever, samt en skriftelig oppsummering hvor testeren forteller hva han likte, ikke likte, osv.

Last gjerne ned Startup Success Podcast #20, som går i dybden på UserTesting.com.

Testcrowd 3: BrowserMob
Dette er en litt annen form for crowdsourcing. Kanskje er det mer riktig å kalle det cloudsourcing. BrowserMob automatiserer load-testing av websiden din ved hjelp av virtualisering, og viser deg nøyaktig hvordan siden oppfører seg i ulike browsere under høy last. Startup Success Podcast #18 intervjuer Patrick Lightbody som står bak BrowserMob.com, så lytt gjerne på det hvis du er insteressert.

Mange andre typer crowdsourcing..

Sammen med en kollega har jeg forsøkt meg litt på et crowdsourcing-konsept selv også, nemlig The Forecast Exchange, hvor man kan tappe kunnskapen til en gruppe mennesker for å spå om fremtiden. Nå i mai kjører vi andre runde med beta-testing, og tar du en titt på forsiden kan du se hvor stor tro brukerne har bl.a. på hvordan det vil gå med den norske børsen fremover, om Liverpool kommer på andreplass i premiere league, og om Norge vinner melodi grand prix.

Ting som Open Source Software, Wikipedia og StackOverflow er også varianter av crowdsourcing. Uservoice, som vi bruker på Forecast Exchange, er en crowdsource facilitator som gjør det mulig for oss å få tilbakemelding fra brukerne om hva de vil ha i produktet fremover. 99designs er et crowdsourcing community hvor du kan legge opp en konkurranse for grafiske designere, hvor folk konkurrerer om å komme opp med et design som du er villig til å betale for.

Er du interessert i flere slike crowds kan du ta en titt på denne listen fra Open Innovators over plattformer og tjenester. Crowdsourcing i ulike former er fremtiden. Det betyr mindre og mindre hvor man befinner seg i verden, og de som klarer å tappe kunnskap og talent over internett vil komme seirende ut av de komende årene. Dette er et utrolig spennende felt, og jeg gleder meg til å se mange, nye måter å utnytte dette på fremover.

I går arrangerte jeg min første Coding Dojo. Jeg har tidligere skrevet om at jeg har lyst til å prøve ut dette formatet på NNUG, men tenkte det ville være et bra første steg å forsøke det på jobben.

En Coding Dojo er et møte hvor en gruppe utviklere jobber sammen for å løse en programmeringsoppgave. Fokuset er å lære seg og praktisere teknikker. Man bruker testdrevet utvikling og parprogrammering, og utviklere av ulike erfaringsnivåer skal føle seg velkomne til å bidra. Hvert femte til syvende minutt rullerer man, slik som dette:

Dojo er japansk, og er navnet på et sted hvor man lærer kampkunst, som for eksempel Judo og Karate. Innenfor disse disiplinene foregår læring gjennom eksempel; man observerer hvordan de som er høyest gradert utfører sine teknikker, og forsøker så selv gjennom å imitere det man har sett. Dette prinsippet kan også fungere innenfor programmering.

Jeg valgte en oppgave designet for Coding Dojo’s kalt KataTexasHoldEm, beskrevet her. Jeg hadde forsøkt meg på samme oppgaven kvelden før, og skjønte raskt at oppgaven sansynligvis var for omfattende for de to timene vi satte av til dette. Men jeg håpte likevel den ville gi oss endel erfaring både med parprogrammering og TDD, samtidig som det var et passe spennende domene å modellere.

Det er meningen at publikum skal kunne komme med kommentarer til paret som programmerer. Vi var derimot bare fire utviklere som deltok, og dette førte til at vi i praksis var én driver og tre navigators som uttrykte meningene sine i munnen på hverandre. Kvartett-programmering viste seg å være noe langsommere enn parprogrammering, men også veldig stimulerende. For fremtiden vil jeg likevel forsøke å kontrollere publikum bedre.

Jeg følte vi lærte mest om TDD. Vi så blant annet flere ganger hvordan vi tok for store steg, som gjorde at vi mistet kontrollen noen ganger. Jeg la stor vekt på at man skal få testene grønne så raskt som mulig, og så bruke mer tid på å forbedre og refakturere koden – noe som ble klart for meg etter at jeg leste Kent Becks TDD bok. Vi gjorde også refaktureringer som virket unødvendige.

Etter at vi var ferdige (dvs etter at tiden var ute) snakket vi om hvordan det hadde gått, og vi sammenlignet også løsningen med det jeg hadde gjort kvelden før. Vi ble bl.a. enige om at vi hadde hatt for lite fokus på å skrive tester som førte til fremdrift, og i stedet fokusert for mye på unntakshåndtering – en vanlig feil som ofte fører til at man missliker TDD. Det er viktig å huske at TDD ikke dreier seg om testing, men å bruke tester til å drive design av kode. Dette var nok grunnen til at jeg hadde hatt fått implementert en større del av løsningen i løpet av samme tid.

Jeg lærte forsåvidt endel av å gjøre oppgaven alene også. Det var spennende å se hvordan designet mitt endret seg for hver ny test jeg skrev – endringer jeg ikke hadde forventet. Jeg fikk også tatt i bruk en annen ting jeg blogget om for en stund siden, nemlig Specification pattern. Her er for eksempel objektet som implementerer regelen for om en pokerhånd inneholder ett par:

Å implementere forretningsregler som objekter er utrolig kraftig.., absolutt noe jeg anbefaler.

Så, for å oppsummere: Coding Dojo var absolutt en suksess. Mine kollegaer syntes det var et par spennende timer, det var lærerikt, og gav oss inspirasjon. Og jeg har fått enda mer tro på at dette er noe som kan egne seg som et alternativt format på brukergruppemøter i NNUG.

Knagger: Coding Dojo, Contiki, NNUG, parprogrammering, Specification Pattern, TDD

Dette er en oppfølgingspost til artikkelen hvor jeg beskrev hvordan jeg lager små SOA komponenter. Nå viser jeg hvordan jeg tar kompionenten i bruk, og måler hvor bra den virker.

Jeg oppretter et nytt Console application prosjekt, og legger til en Service Reference hvor jeg bruker adressen definert i BrainSpill tjenesten: http://localhost:8000/BrainSpill/service/mex. Dette genererer en MessageRepositoryClient klasse med metodene jeg tidligere definerte i IMessageRepository i BrainSpill-prosjektet. Vil jeg nå for eksempel sende en ny melding til BrainSpill kan jeg gjøre det slik som dette:

For å se hvor bra tjenesten håndterer mange requester forsøker jeg å opprette 100 meldinger om gangen i en loop, og måler hvor lang tid det tar:

Resultatet:

Ikke så verst – i overkant av et halvt sekund for å sende og motta 100 requests og lagre dem i basen. For å se om performancen blir dårligere om det finnes mange meldinger i basen fra før kjører jeg testen en del ganger til. Men det ser ikke ut til å ha noen spesiell betydning:

Jeg bør også teste hvordan tjenesten oppfører seg med mange, samtidige brukere, og fyrer derfor opp seks command-winduer som hver kjører testprogrammet 10 ganger etterhverandre. Det vil altså si at jeg har seks ulike klienter som forsøker å hamre inn meldinger på en gang, samtidig som de hele tiden spør tjenesten hvor mange meldinger som finnes.

Resultatet varierte en god del. På det minste tok det nå 1,6 sekunder å sende 100 meldinger, på det meste helt opp i 16 – de fleste brukte et sted mellom 4 og 10 sekunder.

Jeg må også teste metoden for å hente ut ferske meldinger: GetLatestMessages. Jeg skriver om programmet mitt til å hente ut de 10 siste melding.

Første gang jeg kjører testen tar det hele 3,3 sekunder, men når jeg forsøker flere ganger tar det bare litt over 0,6 sekunder. Jeg antar at det er db4o-databasen som cacher noe. Venter jeg en stund og så forsøker igjen, tar det igjen i overkant av 3 sekunder første gang, deretter 0,6.

Jeg er interrestert i å se om cachingen blir påvirket av at det kommer inn nye meldinger. Dvs. om det alltid vil ta lang tid første gangen etter at en ny melding har blitt lagret. Jeg skriver derfor et program som henter de siste meldingene noen ganger, legger inn noen meldinger, og så henter nye meldinger igjen:

Resultatet bekrefter at cachingen ikke blir påvirket av at det kommer inn nye meldinger:

Knagger: BrainSpill, db4o, SOA

Kent Beck er en legende innen smidig softwareutvikling: Han er opphavsmannen til Extreme Programming (XP). Han var en av 17 personer som utformet og signerte the Agile Manifesto. Sammen med Ward Cunningham gjorde han CRC-kort populært, og han lagde testrammeverket JUnit sammen med Erich Gamma. Og han er en av de mest sentrale personene innen testdreven utvikling (TDD).

Kent har skrevet mange bøker, og en av dem er Test-Driven Development: By Example, utgitt i 2002.

Denne boken har et uvanlig format. Den er delt inn i tre deler, og i stedet for å fortelle om TDD og argumentere for hvorfor det er en bra teknikk, så tar forfatteren deg i de to første delene av boken med på et par programmeringsøkter. Hver del har rett og slett et problem som skal løses, og Kent koder og forklarer underveis hva han tenker og hvordan han går frem.

I den første delen implementerer han penger som støtter flere valuta, og han bruker Java som programmeringspråk (Java er så likt C# at det er lett å ta feil av og til). Målet er å illustrere rytmen i testdreven utvikling.

Og i den andre delen skrur Kent opp vanskelighetsgraden et par hakk og implementerer faktisk et rammeverk for enhetstesting. Han lærer oss altså om slike rammeverk gjennom å implementere det, og han bruker testdreven utvikling for å gjøre det. Han tester faktisk koden sin med rammeverket som han koder, hvilket jo er ganske snedig. Han gjør dette eksempelet i programmeringspråket Phython – og selv om du ikke har noen erfaring med det språket så klarer du å henge med, for han forklarer det du trenger underveis.

Etter å ha lest de to første tredjedelene av boken føler du at du har fått bra tak på TDD. Og da går Kent endelig over til å ”snakke” litt også. Del tre handler om patterns i TDD, dvs en litt mer formell forklaring av hvordan man går frem, og hva som er viktig å tenke på. Han går også inn på enkelte design-patterns og refaktureringsteknikker – refakturering er tross alt en meget sentral del av testdrevet utvikling.

Det aller siste kapittelet handler om å mestre TDD. Her stiller han en del spørsmål som får leseren til å tenke. Av og til hinter han til hva svaret kan være, andre ganger lar han spørsmålet henge der. Han knytter også TDD opp mot Extreme Programming, men boken snakker generelt lite om dette.

Jeg har gjort noe TDD fra tid til annen, men er langt fra erfaren – og Test-Driven Development: By Example gav meg mye god kunnskap og forståelse – både om hvorfor TDD fungerer, og hva jeg har gjort “galt” i min egen praktisering. Å lese boken er ingen erstatning for å øve, øve, øve – for det er kun slik man kan lære det orntlig. Men den fungerer ypperlig som en introduksjon og inspirasjon til testdreven utvikling for utviklere som allerede har noen års erfaring og som er interessert i TDD, men enten aldri har forsøkt det selv eller ikke helt har fått det til.

Du kan se en smakebit av boken på Google Books om du vil. Og hvis du allerede har lest den, eller en annen god bok om TDD, er det veldig kjekt om du legger igjen en liten kommentar.

Knagger: TDD, Kent Beck, Agile, Smidig, Patterns, Refakturering, Enhetstest

Code Kata er et begrep skapt av Dave Thomas, forfatteren av The Pragmatic Programmer. Som i karate og andre kampkunster som praktiserer kata, er code kata en praksis som forbedrer dine ferdigheter gjennom øvelse og repitisjon.

På codingdojo.org fant jeg i dag en god liste over slike programmerings-kataer. Og siden jeg er syk og holder meg hjemme i dag så tenkte jeg at jeg skulle forsøke meg på en.

Så jeg satte i gang med KataBankOCR. For en gangs skyld gjennomførte jeg 100% testdreven utvikling, og det hjalp meg veldig med å gjennomføre denne oppgaven. Det tok et par timer og 33 enhetstester å lage en løsning jeg var fornøyd med, og det var både gøy og lærerikt. Jeg fikk også praktisert noe jeg har blitt spesielt oppmerksom på etter å ha lest Code Complete, nemlig bruk av tabelldrevne metoder. Dette gjorde koden min mye enklere enn om jeg i stedet hadde brukt logiske strukturer som if og switch case.

Er du interessert i å bli en bedre programmerer med code katas så anbefaler jeg å ta en titt på CodeKata siden til Dave Thomas.

På TechEd i Barcelona fikk unit-test guru Roy Osherove spørsmål om han kunne si noe om unittesting av grensesnitt, det være seg WinForms eller Web gui. Hans svar var klinkende klart:

“Don’t do it!!!”

Ikke lag unit tester for UI. Hvis du vil teste UI logikken din kan du bruke en MVC modell eller lignende, men ikke forsøk deg på å teste selve brukergrensesnittet. Det er for utfordrende rent teknisk til at det er verdt det, i tillegg til det faktum at UI er svært dynamisk – både over tid men også med tanke på konfigurasjons- og profil-avhengigheter.

Så var det avklart en gang for alle. Watin kastes herved i bit-bøtta.

Jeremy D. Miller kan i dag informere om at det nå eksisterer en .net versjon av watir (uttales “water”), nemlig watin (uttales “what-in”). Disse produktene/biblotekene lar deg automatisere web testing.., med henholdsvis Ruby og .net.

Jeg har foreløpig brukt watir til helt enkle automatiseringsoppgaver, men kanskje watin kan få litt mer fart på selve test-utviklingen.., skal definitivt ta en titt på dette.

Et par uttalelser om WatiN:

“… it feels like it should have shipped out of the box with Visual Studio Team Edition for Software Testers.”

Bruce McLeod
Principal Consultant for Devtest Pty Ltd.
www.devtest.com

“What a great tool!!! We are using it with CruiseControl.Net. We run roughly 1k tests each build.”

David Strickland

Vice President of Development

Swingvote, LLC

Har lest og testet Ruby i hele fem dager nå – og er helt frelst. Jeg har også funnet et område hvor jeg garantert kommer til å benytte Ruby i jobben (om ikke min kommende arbeidsgiver har investert i noe fancy greier da).., nemlig enhetstesting av web UI! Watir er et bibliotek til Ruby som lar deg helautomatisere IE, og støtte for flere browsere kommer. Du kan også (med litt jobb) plugge unit tester du lager i ruby/watir inn i NUnit, om du skulle ønske det.

Uttalelser folk har kommet med etter å ha oppdager Watir:

“I’ve been trying to find the Holy Grail of Automated Web UI Testing….
And the one I’m currently enamored with is Watir.” — Scott Hanselman

“I wanted to run around my office dancing and celebrating.” — Beth Ferguson

For mer om Ruby, se mine tags..

—

Jeg surfer ganske mye på ulike programmeringssider for tiden, og oppdaget da denne litt morsomme siden for oss nerder: 99-bottles-of-bear.net! Her kan du se den kjente øl-sangen implementert i forskjellige språk på (p.t.) 927 ulike måter.

Og da fikk jeg forresten lyst til å vise mitt siste program.., ikke et eksempel på hvor lesbar Ruby kode er akkurat – har har jeg forsøkt å obfuskere litt:

Noen som ser hva dette programmet gjør? Send inn forslag…