Frukostseminarium om att komma igång med TDD på befintliga system

clock maj 3, 2010 12:08 by author Daniel Hognert

Iptor Konsult bjuder in till frukostseminarium i Göteborg den 20 maj och Stockholm den 21 maj kl. 08.00 - 09.30

TDD på befintliga system - Hur kommer man igång med TDD om man inte vågar göra ändringar i sin kod?

Fler och fler inser nyttan med Testdriven Utveckling, TDD. Med hjälp av flera typer av automatiserade tester kan man nå helt nya nivåer av kvalitet och flexibilitet på sin mjukvara.

Men hur gör man om man ansvarar för ett befintligt system som man knappt vågar göra ändringar i? Vissa typer av tester kräver ju att koden görs testbar först.

På detta frukostseminarium presenteras några olika typer av automatiska tester och hur man kan komma igång med TDD även i befintliga applikationer och projekt.

Frukostseminariet är gratis, och frukosten är uppdukad från klockan 08.00.

Plats:

Göteborg den 20/5 kl 08.00 - 09.30
Iptor Konsult AB
Falkenbergsgatan 3 (6:th floor)

Göteborg


Stockholm den 21/5 kl 08.00 - 09.30
Iptor Konsult AB (IBS Kundcenter)
Hemvärnsgatan 8

Tunnelbanestation Vreten
Solna

Anmälan:
Du anmäler dig till detta frukostseminarium genom att skicka ett e-mail till konsult (snabel-a) iptor.com.



Pimp My Code

clock februari 2, 2009 09:06 by author Magnus Härlin

Under förra veckan gå gick Pimp My Code av stapeln i Göteborg. Det var en väldigt lyckad och intressant kväll.

 

Första sessionen höll Joakim Sundén i. Han pratade om kodkvalitén och proffesionalismen hos programmerare. Några av dom intressantaste punkterna som  han tog upp var

·         ”Broken window theory” – Om man har ett krossat fönster i ett hus och inte reparerar det kommer det leda till att flera fönster krossas och att det är större risk för inbrott eller skadegörelse. Det samma gäller för kod, om man ser många fulfixar så är det större risk att det leder till fler.

·         Förändring börjar alltid hos en själv. Om man själv har attityden att alltid checka in bättre kod än man checkade ut så är det ett bra utgångsläge.

·         Parprogrammering ger 60 % buggupptäckningsgrad jämfört med att sitta och koda själv.

·         Parprogrammering tillsammans med TDD ger ca 98 % buggupptäckningsgrad jämfört med att sitta och koda själv utan TDD.

 

Andra sessionen höll Patrik Löwendahl och den handlade om S.O.L.I.D. principerna som jag nämnt tidigare i ett tidigare inlägg. Jag kommer att lägga upp en post om varje enskild princip så jag nämner inte så mycket mer om det här.

 

Tredje sessionen höll Fredrik Normén och den handlade om Refaktorering till Mönster och exemplet var ett väldigt klassiskt på hur en swith sats lätt kan växa sig lite för stor eller riskera att göra det och hur man genom att använda Separation Of Concerns kan lösa det snyggare. Jag kommer att ta upp det i inlägget om Separation Of Concerns som är den första principen i S.O.L.I.D.

 Sista sessionen höll Dag König och den handlade om Kodkvalité och hur man kan mäta den med olika verktyg. Bland annat fxCop som man kan koppla in till Visual Studio och sen även Visual Studios egna code metrics. Med fxCop kan man välja vilka regelbibliotek man vill att den ska använda och så får man veta om koden bryter mot några av dom. Den kan vara namnstandard som inte följs eller att man bryter mot best practices. Code Metrics i VisualStudio har några olika kategorier som LinesOfCode, ClassCoupling, CyclomaticComplexity (hur många utgångar en funktion kan ha) och Maintainability Index där bra värden är < 70 men sen finns det förstås alltid undantag.


TDD Exempel

clock november 21, 2008 15:29 by author Magnus Härlin

Det här är ett kort exempel på hur man skulle kunna lägga upp testdriven utveckling av en funktion som ska ta in en sträng och parsa den och returnera ett nummer.

I TDD är det tre steg man alltid gör om och om igen tills allt är klart, stegen är:
• Skriv ett test som inte går igenom
 Ingen kod utan ett fallerande test
• Få testet att lyckas
Med så enkel kod som möjligt
• Gör koden bättre
Refaktorera

När man skriver första testet ska det vara det enklaste sättet att få funktionen att lyckas. Allra enklaste hade jag tyckt var att skicka in en tom sträng, men eftersom kravet inte sa någonting om det så blir det första jag får man först se till att kravet är tydligt genom att fråga sin chef eller kund istället för att gissa. Nu har vi fått ett tydligare krav och vet att skickar man in en tom sträng ska funktionen returnera 0.

Vi börjar skriva testet, skapar en i stort sett tom funktion så att vi kan kompilera projektet och köra testet.


//Testprojektet
        [TestMethod]
        public void CanParseEmptyStringToInteger()
        {
            ParseStringToInteger parser = new ParseStringToInteger();

            int actual = parser.ParseToInteger(String.Empty);

            Assert.AreEqual(0, actual);
        }

//Logik klassen
        public int ParseToInteger(string stringToParse)
        {
            return -1;
        }

När vi kör testet första gången får vi ett rött fallerande test precis som väntat.

Det absolut minsta vi behöver göra för att få koden att fungera är att ändra så att vi skicka tillbaks 0. Vi uppdaterar koden så att det står return 0;
 i funktionen istället och kör testet igen. Det blir grönt för att testet gick igenom. Kommer det här fungera senare? Det spelar ingen roll! För man koncentrerar sig på ett test i taget och det absolut lättaste sättet att få det att gå igenom var att göra såhär. Då är det rätt sätt.

Uppenbarligen har vi inte täckt in alla krav än så vi skapar ett test till där vi skickar in 1.

[TestMethod]
        public void CanParseStringWithNumberOneInToInteger()
        {
            ParseStringToInteger parser = new ParseStringToInteger();

            int actual = parser.ParseToInteger("1");

            Assert.AreEqual(1, actual);
        }


Testet misslyckas så våran nuvarande kod täcker inte in det nya testfallet än. Vi gör följande uppdatering:

public int ParseToInteger(string stringToParse)
        {
            return int.Parse(stringToParse);
        }


Nu går det andra testet igenom men det första misslyckas. Vi måste lägga till ett sätt för att se om strängen är tom och sen vet vi sen tidigare att vi bara behöver returnera 0 för att kravet ska uppfyllas för det första testet också.

public int ParseToInteger(string stringToParse)
        {
            if (string.IsNullOrEmpty(stringToParse))
            {
                return 0;
            }

            return int.Parse(stringToParse);
        }


Nu vet vi att funktionen gör precis det vi förväntar oss av den. Den parsar en sträng till en siffra och alla krav är uppfyllda och vi skapade först tester från kraven och sen funktioner som uppfyllde testerna.

Är det krav på att vi ska validera det som kommer in kan vi förstås lägga till funktioner för det och fortsätta på samma sätt som vi gjort hittills.

Så lätt är TDD, kan kännas lite konstigt i början man har man väl vant sig vill man aldrig sluta.



Vad krävs för att komma igång med TDD?

clock november 17, 2008 08:41 by author Magnus Härlin

Vad tjänar man på jobba med TDD jämfört med att skriva testen efteråt? I båda fallen skriver man test för samma funktioner och kan få samma code coverage.

 

TDD leder ofta till bättre design och mindre buggig mjukvara. Anledningen är att utvecklare inte motiverade att hitta felen i sin kod utan bara visa att den som fungerar.

 

Vad finns det för problem med att arbeta med TDD? Det är en ganska hög tröskel för att komma igång med det. Dom tre största inlärningsmomenten är:

·         Lära sig skriva bra enhetstest

·         Lära sig att låta testen driva utvecklingen (TDD)

·         Lära sig att göra en bra design

 

I den ordningen är det bra att lära sig momenten också.

 

Vad är det då som gör ett test bra? Framförallt är det att det är lättläst test där det är tydligt vad det testar. Det är absolut inte ett krav att ett test ska testa all funktionalitet i en klass utan hellre flera lättlästa korta test som tydligt testar olika delar av klassen.

 

I nästa blogginlägg ger jag exempel på hur man kan driva designen med test.

 

En best practice för att det ska vara bra design är att följa S.O.L.I.D

·         Single Responsibility Principle (SRP)

·         Open Closed Principle (OCP)

·         Liskow Substitiution Principle (LSP)

·         Interface Segragation Principle (ISP)

·         Dependency Inversion Principle (DIP)

 

För att hitta bra förklaring och översikt över principerna kan man titta in på: http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx

 

Som med allt annat så är bästa sättet att lära sig samtliga delar att öva. Sen är det klart att det kan gå lite fortare och vara roligare om man har någon mer erfaren i teamet som man kan fråga och få guidning av.