A short talk on the whys, whats and how of TDD (in Norwegian), held on Nov 12th 2014 for masters of information technolody students at the Norwegian University of Science and Technology in Trondheim. Based on my previous TDD talks and about 25 minutes long, containing some short code examples in c# and some general advice.
Hei! Mitt navn er Joachim Løvf, jeg er utvikler hos Creuna og jobber for tiden mest med VisitNorway, som jeg har et slags ansvar for.
Visitnorway.com, en portal for turister i inn- og utland som viser frem det Norge har å tilby. Den vedlikeholder og videreutvikler vi.
Visitnorway.com, en portal for turister i inn- og utland som viser frem det Norge har å tilby.
Jeg skal snakke litt om testdrevet utvikling og om hvordan vi I Creuna og jeg ser på det.
Det er ikke lenger et spørsmål OM man skal gjøre testdrevet utvikling, men hvordan.
Konferanser, fagfolk, alle er enige om at dette er veien å gå – de som ikke er det, har bare ikke innsett det ennå.
Vi vet hva vi skal gjøre – vi bare gjør det feil.
58% of software bugs result from test infrastructure and process, not design defects»
TDD er den eneste måten å gjøre ci cd på ansvarsfull måte
20 millioner brukere i Tyskland alene, 10 millioner i Europa, 2 millioner kjøretøy
4-6 utrullinger per dag
Må sikre at det man gjør her borte I systemet, ikke får negative følger et annet sted. Da er TESTENE SIKRINGEN.
Testene er sikringen , eller sikkerhetsselen, som gir trygghet i neste fase.
Og denne tryggheten trenger vi, fordi….
Spesifikasjoner endrer seg, og å endre på noe én plass har en lei tendens til å påvirke noe helt annet
Om systemet er understøttet av tester, altså har disse sikringene som jeg nevnte, kan endringer gjøres i visshet om at eksisterende funksjonalitet ikke berøres.
Det vi begynner å lage, og leverer i versjon 1, er ofte langt unna det kunden eller bestiller vil ha i versjon 2 eller 3.
Red – green - refactor
clockmock
Xunit, “Fact”
Husk: løs kun oppgaven, og løs den så enkelt som mulig.
…og så blir det lov å bruke hodet.
Dete kan noen ganger være riktig, avhengig av algotirmen.
Bruker autofixture til å skape testdataene. Fokuserer på design, ikke på data.