Hvis Jokerens liv er et Junkiegøglercirkusliv må jeg betegne mit nye liv som et pendlerscrumagileliv. (Be warned: det her er en af de lidt bløde artikler om mig selv, og mine erfaringer - sorry).

Fra årsskiftet begyndte jeg at arbejde hos Vertica i Århus, men er stadig bosiddende i Odense. Det at skulle pendle var jeg spændt på da jeg tog imod jobbet, men det har vist sig ikke at være så hårdt som jeg kunne have frygtet. Jeg er som de fleste andre ikke voldsomt imponeret over DSB's planlægningsevner, og oplever dermed fra tid til anden lidt frustrationer. Alt i alt har det alligevel været rimeligt problemfrit at skulle pendle. Det skal siges at jeg ikke pendler hver dag, og arbejder i toget når jeg gør - hvilket naturligtvis også hjælper en del.

Udover at skulle tilpasse mig livet som pendler var det også et skifte til en virksomhed der i langt højere grad arbejder med scrum og agile principper. Det har betydet en noget anden arbejdsgang end jeg var vant til, og jeg må helt klart tilskrive mig den voksende skare af folk der tilslutter sig disse principper.

Scrum har været med til at gøre det lettere at fokusere på det der er jobbet - at skrive software - samtidig med at det giver en dejlig ærlig tilgang til tingene. De gevinster føler jeg allerede i hverdagen, selvom vi ikke selv mener at vi er færdige med at indføre scrum - og bliver man egentlig nogensinde bliver det? Jeg har været til JAOO days om agile udvikling i København, og vores projektledere har er blevet certificerede scrum mastere. Så det er et område vi har fokus på, og det er derfor rart at mærke at investeringen giver afkast - i modsætning til de fleste andre investeringer, som verden ser ud for tiden.

Til den mere tekniske side har jeg haft mere fokus på TDD, DDD og CI - som man ikke kommer udenom som moderne agile udvikler. Uden at være modstander  har jeg altid været lidt skeptisk overfor TDD, men jeg må erkende at jeg er begyndt at mærke gevinsten i form af bedre design, og følelsen af frihed til at refaktorere. Vi holdt codecamp i ANUG regi i starten af marts ved min kollega Daniel Gonzáles Garcia, og det virker til at være et emne der har rimelig stor interesse i communitiet. Forhåbentligt lokker det flere til at begynde at arbejde med frameworks som ASP.NET MVC - som jeg selv er igang med :)

DDD tankegangen har altid været det der faldt mig naturligt, kontra databasetænkning som har en tendens til at bide en i røven når et system bliver tilstrækkeligt omfattende - og dermed uoverskueligt. At vi direkte har fokus på principperne giver en god fælles terminologi, og kombineret med brugen af et ORM gør det livet som udvikler en del sjovere.

CI er for mig noget nyt at skulle bruge i praksis, og én umiddelbar erfaring har været at det fjerner en hel del af smerten ved at skulle udgive webløsninger. Det meste der skrives om CI handler om at få afprøvet den samlede kodebase, og få afviklet sine unittests. Dette er naturligt også et hovedfokus - men det at gøre udgivelse til en mere naturlig del af processen skal bestemt ikke overses som en vigtig gevinst.

 

Test driven development – my two cents.

Unit testing er en metode til at teste at en individuel enhed kildekode fungerer korrekt.  Egentlig har unit testing været brugt i flere årtier, men begrebet har den seneste tid udviklet sig til lige at være et buzzword der er oppe i tiden – især som metodik i form af Test Driven Development. TDD bliver der blogget enormt meget om for tiden – og netop derfor vil jeg ikke kaste mig ud i at forklare hvad det er, men lader det være en forudsætning for at læse videre.

Udbredelsen af TDD/unit testing er en stor del af grundlaget for at Microsoft har kastet sig over at lave MVC frameworket, som et alternativ til den klassiske måde at udvikle ASP.NET applikationer på.

Rob Conery der står bag SubSonic, og nu er ansat hos Microsoft er for tiden i gang med en serie på sin blog som han kalder MVC storefront, hvor han går efter at blive klogere på både MVC og TDD. En sjov detalje han har bemærket er at alle i miljøet snakker om ”at hvis man nu er purist skulle man gøre sådan og sådan”, men han har umiddelbart ikke kunne finde nogen der direkte er purister inden for TDD.

Personligt kan jeg godt se anvendeligheden i TDD, men jeg mener helt klart at der er alt for meget hype om det, og at det bestemt ikke er alting det er velegnet til. Min holdning skyldes helt enkelt to ting; for det første at man ofte ikke har en god nok beskrivelse af hvad man skal udvikle til at man kan skrive en rigtigt god unit test, og for det andet at det ikke altid er noget godt kvalitetsmål. Med det mener jeg at det ikke er alting man kan teste ved hjælp af unit tests, både fordi eksempelvis usability slet ikke er noget mål for en unit test, men også fordi omkostningerne ved at skrive og vedligeholde tests kan være større end gevinsten. Dette er i nogen grad en pointe ”Joel on software” også har fremført, blandt andet ved en tale på Yale.

Jeg laver selv en del applikationer, hvor beskrivelserne er sparsomme, og udviklingen derfor ikke kan undgå at blive ”trial and error” baseret. Ikke forstået som i at der er masser af ”fejl” som sådan i koden (selvfølgelig er der også det), men fordi kundens ønsker ændrer sig markant i løbet af processen. Teoretikeren vil nok sige at så er analysen af projektet ikke god nok, en pointe der ikke går helt tabt på mig, men der er mange kunder hvor det simpelthen ikke er muligt i praksis. Let the religious battle between theory and pragma begin!

Min anden pointe med at det ikke er alting der lader sig unit teste, er selvfølgelig også et spørgsmål om vilje. Brugerflader og sprocs er vanskelige at teste, og selvom man gør sig en masse anstrengelser for at lave unit tests af disse ting er værdien mindre - i forhold til at kunne teste ”rene funktioner”, med kendt input og output. En sidste observation jeg har gjort mig, er at fejl oftere skyldes integrationsproblemer end direkte logiske fejl – og i systemer hvor det er tilfældet er integrationstests i virkeligheden mere formålstjenlige.

Selvom jeg måske nu lyder meget skeptisk, synes jeg at unit tests og TDD er rigtigt godt, til de ting det rent faktisk er opfundet til. Min indsigelse er blot imod den megen hype der er, da heller ikke det er nogen Silver bullet, og jeg føler at anvendeligheden af unit tests har det med at blive overdrevet.

Frameworks og tools – de små måske vigtige forskelle.

De fleste jeg har snakket med der har arbejdet med unit testing kender NUnit frameworket, som nok er det mest udbredte framework til unit testing i .NET. Frameworket er oprindelig portet fra JUnit og har efterhånden en del år på bagen.

Der findes imidlertid også to andre udbredte open source  alternativer som er MbUnit og XUnit – forskellene imellem de tre frameworks er relativt små, men som man siger ”god is in the details”.

MbUnit omtales som NUnit på crack, og er et framework der er udviklet til at være mere udvidelsesvenligt end NUnit er. Det er i dag nok det mest advancerede unit testing framework og giver blandt andet mulighed for at man via attributter beskriver data der skal passes til en testmetode, og derved kan den samme metode kaldes flere gange hvor forskellige grænseværdier testes.

[RowTest]

[Row("Christian", "123")]

[Row("Christian", "", ExpectedException = typeof(InvalidUserException))]

[Row("", "123", ExpectedException = typeof(InvalidUserException))]

[Row("Christian", "qwerty", ExpectedException = typeof(InvalidUserException))] 

public void CheckUserLogins(string name, string password)

Det har desuden også en feature til at rulle database ændringer tilbage ved hjælp af attributterne SqlRestoreInfoAttribute, RollBack og RestoreDatabaseFirst.

XUnit findes på codeplex, og det er udviklet med henblik på at skulle passe bedre ind i .NET miljøet, samtidig med der er ryddet op i attributter og assertions med henblik på at få pænere testkode. Jeg kan personligt virkelig godt lide at det gør brug af generics, og at det giver mulighed for at lave en slags aspect oriented programming.

Generics bruges blandt andet til fixture setup, sådan at man ved at bruge IUseFixture<T> kan passe klasser til ens testmetoder, som man så kan arbejde med.

public class MyTests : IUseFixture<MyFixture>, IDisposable

{    

    public void SetFixture(MyFixture data)    

    {                

        data.SomeMethod();    

    }

}

Aspect oriented programming fungerer ved at man laver ens egne attributter ved f.eks. at extende BeforeAfterTestAttribute, som blot er at overskrive et par metoder.

public class PrepreDatabaseAttribute : BeforeAfterTestAttribute

{    

    public override void Before(MethodInfo methodUnderTest)    

    {        

        // Do your pre-test stuff    

    }    

    public override void After(MethodInfo methodUnderTest)    

    {        

        // Do your post-test stuff    

    }

}

Udover et decideret testframework skal man også bruge et tool til at udføre ens tests og give overblik over hvad der går godt og hvad der fejler – de berømte grønne lamper man nyder at se lyse når man benytter TDD. NUnit har den fordel at der følger et lille separat tool med der kan lige præcis det, og som virker ganske fint til de flestes behov. Til XUnit er der et lignende tool under udvikling, men det er stadig eksperimentalt og virker ikke just som et færdigt tool endnu.

Alle 3 frameworks kan imidlertid også bruges sammen med TestDriven.NET og ReSharper , som begge er bedre bud hvis man vil have en ordentlig brugsoplevelse.

 TestDriven.NET er et add-in til Visual Studio, som giver mulighed for afvikling af unit tests, og er det tool flertallet bruger. Jeg må dog erkende at jeg synes TestDriven.NET er relativt dyrt, taget i betragtning af at det startede som et gratis værktøj og i bund og grund stadig er et simpelt add-in.

Resharper er også et Visual Studio add-in som man kan skaffe til rundt regnet samme pris som TestDriven.NET, men man får bare meget mere med i pakken, da det blandt andet også tilbyder hjælp til refactoring, formattering og kode analyse. Som det fremgår er jeg selv faldet lidt for ReSharper, selvom jeg var lidt skuffet over at det endnu ikke er klar i en .NET 3.5 udgave, så kodeanalysen fejler hårdt på LINQ queries o.lign. En ny version målrettet .NET 3.5 skulle dog være på trapperne, så jeg må bare leve med at slå kodeanalyse fra indtil da.

Test af sprocs – der hvor det bliver mere vanskeligt.

Når jeg nu tidligere har nævnt at jeg mener sprocs er vanskelige at teste, skylder jeg også at beskrive hvordan man kan gøre det - og uddybe hvad jeg mener med at værdien i mine øjne er mindre end ved test af mere isolerede funktioner.

Jeg læste i går en ganske god artikel i MSDN magazine omkring brugen af LINQ to SQL til test af sprocs. Der var egentlig ikke et perspektiv der i første gang havde slået mig, men det er egentlig klart at LINQ to SQL er godt til at teste sprocs på meget lettere vis end det var muligt i tiden pre-LINQ. Helt enkelt består sproc tests af.

·         Klargøring af database, så den er i en velkendt tilstand.

·         Afvikling af sproc.

·         Test af databasens tilstand er som ønsket.

De tre trin lyder simple nok, man har naturligvis en række komplikationer i forhold til det her med databasens tilstand. Det letteste er sandsynligvis at arbejde med en tom kopi af databasen, som gerne er separat fra ens anden test/udviklings database der typisk indeholder en røvfuld ”real world” data. Ved hjælp af LINQ kan man så faktisk med meget få linjer kode slette alle data i en tabel, og indsætte de data man ønsker som grundlag for testen.

Ligeledes kan man i LINQ afvikle den sproc der skal testes, og så er der egentlig ”bare” tilbage at teste databasens tilstand efterfølgende. Et godt tip fra artiklen er at hente alt data i en tabel, hashe det ved hjælp af eksempelvis en MD5 hash. Resultatet kan så meget enkelt sammenlignes med en hash som man udregner ved udformning af testen – noget der kan være en kende besværligt, da det at tage hashen første gang man afvikler koden kun beviser at resultatet er det samme ved efterfølgende afvikling og ikke nødvendigvis om det er korrekt.

Få overblik med Unit testing af sprocs

En anden måde at bruge unit tests på i forbindelse med sprocs, som jeg selv har været med til at implementere er at skrive en parser der undersøger hvilke sprocs man kalder fra sin kode og sammenligne med de sprocs der rent faktisk findes i databasen. Selvom det ikke er nogen test af funktionaliteten som sådan, kan det på store projekter bruges til at teste om de sprocs man kalder findes og omvendt om man har sprocs der ikke længere bliver brugt.

Lidt i samme boldgade kan man skrive en unit test der læser ens sprocs ud, og gemmer dem i databasen igen - giver dette en exception er det en god indikation af at sproc’en er knækket. Igen er det ikke nogen gylden løsning da man ikke finder logiske fejl og ikke engang alle slags fejl på den måde. Det er imidlertid et simpelt værktøj, som har sin berettigelse i at det kan give overblik og finde alvorlige problemer med meget simple midler.