Denna gång tänkte jag prata om TDD, jakrakning och framför allt…fokus.

Jag kanske ska ge lite mer sammanhang.

För ett par veckor sedan var vi på Valtech på vår årliga konferens. En av eftermiddagarna då ägnades åt Open Space, och en specifik diskussion jag var med i var “jakrakning” (se Yak shaving).

En av mina kollegor, Gabriel Falkenberg, har en mycket bra struktur för en lyckad jakrakning:

1. Raka rätt jak! (Är detta problem värt att djupdyka i?)
2. Raka den väl! (Gå till botten med detta problem, att gå halvvägs är bortkastad tid!)
3. Håll jaken rakad! (När du väl löst problemet, se till att det inte uppkommer igen. Tala om det för kollegor, blogga om det etc.)

Det här är berättelsen om en “jakrakning” jag gjorde för ett tag sen. Och denna bloggpost är min “Håll jaken rakad”-manifestation för detta problem.

Jag jobbade i ett projekt där jag hade möjligheten att använda några av de verktyg jag tycker gör mig mest produktiv (Ruby on Rails, Rspec etc.). För en av webapplikationerna vi jobbade med märkte jag att ett test tog väldigt lång tid att köra.

    $ time rspec spec/models/simple_spec.rb
    .
    Finished in 0.24208 seconds
    1 example, 0 failures

    real    0m29.572s
    user    0m25.265s
    sys 0m2.632s

Det tar alltså 29 sekunder att köra en spec-fil med ett exempel i!! (I det här fallet är det ett väldigt enkelt test utan databasanrop)

Inte acceptabelt, tänkte jag. Något måste vara fel på min lokala dator (det är inte världens nyaste laptop). Jag gick och frågade team-kamrater, och fick bekräftat att testerna tog nästan lika lång tid för dem med.

Det var då jag, istället för att lägga till en väldigt liten feature, började raka en jak…

Vad är problemet?

För att bedriva effektiv TDD (testdriven utveckling) är en av de viktigaste sakerna att du får snabb feedback på om dina tester går igenom, så att du raskt kan fortsätta utan att tappa fokus. Jag såg flera varningsklockor i detta sammanhang.

1. Jag kände själv att jag tappade fokus, och till exempel började läsa mail, kolla twitter eller nån websida etc. Då kunde det istället för 29 sekunder ta flera MINUTER innan jag insåg att jag halkat iväg, och återgick till testet, men hade då helt tappat fokus.
2. En team-kamrat sa: “Jag brukar inte skriva så mycket tester för den komponenten för att det tar sån tid att köra testerna” (Varning, varning!)

För att följa jakrakningsstrukturen:

1. Raka rätt jak

   De skäl jag skrivit ovan tyckte jag var tillräckligt för att investera en del tid och kolla efter alternativa sätt för att köra mina tester med snabbare feedback.

2. Raka väl!

   I detta fall så insåg jag rätt snabbt att det var själva initialiseringen av Rails som tog så lång tid. Jag började kolla efter sätt att snabba upp det och fastnade för verktyget Spork, som låter en starta en test-server som man sen kör sina tester mot.

   Om jag då startar spork-servern, och kör samma spec som ovan så får jag:

       $ time rspec --drb spec/models/simple_spec.rb
       .
       Finished in 0.30239 seconds
       1 example, 0 failures
   
       real    0m1.075s
       user    0m0.263s
       sys 0m0.074s
   

   Alltså, testet tar allt som allt ca 1 sekund istället för 29 sekunder! En hygglig förbättring!

   Ännu trevligare blir det om man lägger till en komponent till, Guard-spork, som kan monitorera när filer ändras och i så fall köra relevanta tester automatiskt. För mig var det oerhört värdefullt för att bedriva TDD, och att ta pauser när jag själv ville och inte när verktyget bestämde att jag skulle vänta!

   Om det är någon som jobbar med Rails och har samma problem som jag hade, kolla in Guard och Spork. Syftet med denna bloggpost var dock att följa ett strukturerat jakrakningsrecept, så låt oss titta på punkt 3.

3. Håll jaken rakad!

   När jag hade löst mina problem så använde jag det förstås själv först och experimenterade med en del inställningar. Nästa del var att jag tog upp det på ett teknikmöte vi hade på dåvarande uppdrag (med ca 15 andra utvecklare). Där bestämde vi att lösningen skulle läggas till i projektets byggscript (Gemfile i Ruby) och README-fil så att alla fick samma enkla tillgång till snabba tester.

   Och till sist, förutom att dokumentera det för detta uppdrag, så ser jag denna bloggpost som ett sätt att ytterliggare sprida kunskapen till andra därute som inte hittat dessa bra verktyg på Github eller annanstans.

   Jag anser att jag följt Gabriels jakraknings-strategi väl, och några av mina teamkamrater var helt lyriska över hur de verktyg jag hittade hjälpte dem. Så jag skulle säga att detta var en lyckad jakrakning, och väl värd investerad tid.

Har du rakat någon jak? Var det lyckat eller misslyckat? Berätta gärna!