F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH

Relevanta dokument
F4 Testning och Parprogrammering i XP. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH

F2 XP Extrem Programmering översikt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Görel Hedin Datavetenskap, LTH

F2 XP Extrem Programmering översikt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Görel Hedin Datavetenskap, LTH

Agil projektmetodik Varför och vad är det?

Testdriven utveckling. Teorin bakom testdriven utveckling. Bakgrund. Januari 2009, KTH. Alexander Tarnowski

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Agil programutveckling

F2 XP Extremprogrammering översikt

F6 Arkitektur, Planering. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Några principer för effektiv enhetstestning

XP-projekt: En fördjupning

Institutionen för datavetenskap HT /2008. Testning med JUnit

Sammanfattningar Essentials of Software Engineering

Några grundläggande begrepp

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

LUNDS TEKNISKA HÖGSKOLA EDAA01 Programmeringsteknik fördjupningskurs Institutionen för datavetenskap HT 2015

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer

Testplanering, test-first, testverktyg

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016

Den Röda Tråden. Vi kan ta fram arkitekturkrav. Vi kan ta fram arkitektur och design. Vi kan skriva Clean Code KRAV DESIGN IMPLEMENT VISION TEST

Kritik av Extrem Programmering

JUnit. Junit Unit Testing. JUnit 3. JUnit 3 forts. Villkorskontroller i test. Exempel JUnit3

Föreläsning 4 IS1300 Inbyggda system

Enhetstester på.netplattformen

Lösningsförslag till omtentamen för TDA540 Objektorienterad Programmering

Agil testning i SCRUM

Versionshantering. Jan Erik Moström

Mer om kodkvalitet. Mer om kodkvalitet. Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité?

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH

Visuell GUI Testning

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7

Användarcentrerad systemdesign

Kvalitetssäkra ditt projekt med kontinuerlig integration

A ToolGuide for Eclipse: En fördjupning i några av verktygen i Eclipse och hur de underlättar XP s practices

Teststrategier och Testcertifiering. Per Strandberg, Maj 2013

Note to programmers. Embrace Change! Extreme Programming? Fyra basaktiviteter. 12 Practices / sedvanor. Vad är Extreme Programming

Kompilering och exekvering. Föreläsning 1 Objektorienterad programmering DD1332. En kompilerbar och körbar java-kod. Kompilering och exekvering

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Linköpings universitet 1

Creo Customization. Lars Björs

Laboration: Whitebox- och blackboxtesting

F5 Enkel Design, Refaktorisering. EDAF45 Programvaruutveckling i grupp Projekt Görel Hedin, Boris Magnusson,Datavetenskap, LTH

Scrum + XP samt konsekvensanalys

Metoder och verktyg för funktionssäkerhet

Exercise 4a: Test 2 ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15. Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT15 Exercise 1

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Felsökning. Översikt. Felsökning (debugging) Kodstandard. Kommentarer. Kommentarer. Praktiska råd

Förändringskontroll i XP-team. Love Johansson (d00lj), Joakim Persson (d00jp)

Att skriva till och läsa från terminalfönstret

Vad betyder TDD? Test Driven Design?

F6 Arkitektur, Planering

Beijer Electronics AB 2000, MA00336A,

Classes och Interfaces, Objects och References, Initialization

XP vs. Tillverkningsindustrin

Senaste trenderna från testforskningen: Passar de industrin? Robert Feldt,

Aktivitet ett: Kommunicera! Aktiviteter i praktiken. Parprogrammering. Aktiviteter. Parprogrammeringens sju myter. Parprogrammeringens sju myter

TDP005. Föreläsning 2. Filip Strömbäck

Agile-metoder, XP och ACSD

Coaching av programvaruteam EDA270, djupstudie: Praktisk SCM användning i XP-projekt

Föreläsning 3 Verifiering och Validering

F6 Objektorienterad design. ID1004 Objektorienterad programmering Fredrik Kilander

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer

DevOps i Verkligheten

AGILA METODER. (för oss som inte kodar) Nina Berlin

Programvaruutveckling i grupp Projekt EDA260 (D2, C4, E4, F4, I4, Pi4): F1Introduktion. Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Objektsamlingar i Java

1 Comparator & Comparable

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Programvaruutveckling i grupp Projekt EDAF45 (D2, C4, E4, F4, I4, Pi4) - 7,5HP F1Introduktion. Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Användarcentrerad systemdesign

2.1 Installation of driver using Internet Installation of driver from disk... 3

Designmönster, introduktion. Vad är det? Varför skall man använda mönster?

Verifiering & validering -

Testautomatisering. BDD, RSpec

Överlagring, static, testning, formella metoder och undantag! Förelasning 13!! TDA540 Objektorienterad Programmering!

Identitet och ekvivalens

HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN)

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Verifikation, validering och testning

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt

D J U P S T U D I E I E D A S I M P L E C O D E A N D D E S I G N

Abstrakta Klasser 2. Kodning är bara en liten del i programvaruutvecklingen 6% 1% 6% Abstrakta Klasser - deklaration. Programutveckling sker i faser

Proj-Iteration1. Arkitektur alt. 1

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP

Filhanterare med AngularJS

Lösningar till tentamen i EDAF25

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Filip Strömbäck. Verifikation, validering och testning

12 principer of agile practice (rörlig)

Programvaruutveckling - Metodik 2016 Jonas Wisbrant

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 4 Erik Nilsson, Institutionen för Datavetenskap, LiU

Testautomatisering. Labbar, FitNesse, TDD, BDD

Classes och Interfaces, Objects och References Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Dag König Developer Tools Specialist Microsoft Corporation

SAST Q1. Som att börja arbeta på ett nytt jobb. Testautomatisera med Modell-baserad testning

Att införa Extreme Programming genom processförbättring

Tentamen. 2D4135 vt 2005 Objektorienterad programmering, design och analys med Java Lördagen den 28 maj 2005 kl

Transkript:

F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH 1

XP:s Deltekniker (Practices) 1. Planering Planeringsspelet Regelbundna releaser Hållbart tempo Kund i teamet 2. Utveckling Test-driven utveckling (TDD) Parprogrammering Kollektivt ägande Kontinuerlig integration 3. Kodning och Design Enkel design Refaktorisering Kodningsstandard Gemensam vokabulär 4. Dessutom Gemensamt utvecklingsrum Nollte iterationen Spikes 2

Testning: - Fungerar systemet? Verifiering - Byggde vi systemet rätt? Är systemet (tillräckligt) felfritt? Är systemet (tillräckligt) väldesignat (kan vi modifiera det)? Validering - Byggde vi rätt system? Byggde vi det som kunden förväntade sig? Är användarna nöjda med systemet? 3

Tekniker som förhindrar fel Testning kör programmet på testdata - kontrollera om det ger förväntad respons Granskning (av kod, specifikationer, design ) effektivt men tidskrävande Vi kan bara hitta existerande fel, inte visa att något är felfritt. 4

Testnivåer Hur mycket av systemet är inblandat i testerna? Enhetstester, t ex enskild klass Modultest, t ex ett paket i Java Subsystem, t ex ett lager, komponent Systemtest - hela systemet Integrationstest Allt större delar av systemet testas tillsammans Acceptanstest Tester baserat på användarnas krav. 5

V-modellen

Lager - OSI-modellen https://sv.wikipedia.org/wiki/osi-modellen 7

Vad kan man testa? Funktion (rätt resultat) Användarvänlighet ( usability ) Prestanda, tid och minne, bandbredd Överlastat system, stress testning, 8

Strategier för att ta fram Blackbox testning testfall Välj testfall baserat på specifikationer, API Utifrånperspektiv Whitebox tesning Välj testfall baserat på implementation, intern struktur Test coverage - sträva efter att all kod testas 9

Test coverage Executed during test cases: T1 T2 Flow chart: Production code: x = y; if (c1) then { a = b; } else { a = d; } if (c2) then { e = f; } else { e = g; } z = x+a+e; c1 true c2 true false false T3 T4 Statement coverage: All instructions executed. {T1, T2} or {T3, T4} needed for full coverage Path coverage: All different paths executed. All {T1, T2, T3, T4} needed for full coverage.

Vilken coverage i praktiken? Path coverage typically only considered within each method Path coverage over method calls would lead to extremely many routes. Not possible in practice. In addition, for OO programming, each method call corresponds to a large if-statement over subtypes (dynamic dispatch). Software projects today typically use statement coverage. But note that even with 100% statement coverage, there may still be many bugs in the code... Additional common kinds of coverage: branch coverage: each edge in the flow graph must be executed. loop coverage: each loop must be executed 0, 1 and many times.

När körs testfall? Regressionstestning - nästan alltid Efter en ändring, en integration, Kontrollera att systemet inte regredierar - återfaller till ett felaktigt beteende. Automatisk testning - mindre arbete Ett verktyg (script kanske) Kör igenom testfallen och verifierar (diff) att utfallet stämmer med det förväntade. 12

Testning och Granskning i XP Enhetstester Utvecklarens verktyg för att verifiera sin egen kod Test First Testfallen driver utvecklingen framåt. Automatiserad regressionstestning Alla testfall måste fungera innan integration Acceptanstester Kundens krav för att en story skall vara klar Parprogrammering Kontinuerlig kodgranskning 13

Enhetstester Varje klass testas TestBankAccount void initialbalancezero() void simpletransactions() void withdrawtozero() void smalloverdraft() void largeoverdraft() void depositeliminatesoverdraft() BankAccount SEK balance() void deposit(sek) void withdraw(sek) 14

Exempel på testmetoder @Test void initialbalancezero() { BankAccount account = new BankAccount(); assertequals( Incorrect initial balance, new SEK(0), account.balance()); } @Test void initialbalancezero() { BankAccount account = new BankAccount(); account.deposit(new SEK(50)); account.deposit(new SEK(75)); account.withdraw(new SEK(32)); assertequals( Incorrect simple transaction, new SEK(93), account.balance()); } 15

junit -verktyget 16

A) TestFirst: Skriv testfall före kod 1. Create new test-case Skapa ett nytt testfall 2. Make test succeed Implementera tills testfallen går igenom 4. Integrate changes Publicera ändringar 3. Refactor Förbättra design och kod 17

Test ToDo-Lista Skriv upp alla testfall du kommer på på en ToDo-lista Komplettera listan löpande med fler testfall och önskade refactoriseringar när du kodar. Vid parprogrammering: Partnern håller ordning på ToDo-listan. Test First scenarion ToDo-lista: saldo sätt in pengar ta ut pengar övertrassering ränta kontoutdrag 18

One-step test Vilket testfall skall vi hantera härnäst? Ta ett som inte är trivialt och inte för svårt Något man lär sig av och som för designen framåt. 19

1. Skapa nytt testfall Green 1. Create new test case Error Red Implement test Compile OK Run test fail Error Implement Stub 20

Varför vill vi se testen fallera? Om testen fallerar: Kvitto på att vi tänkt rätt Testen testar faktiskt något nytt Vi vet att testfallet kan fallera på förväntat sätt Men om testen går igenom utan att vi implementera något? Varningssignal har vi tänkt fel någonstans? Har vi kodat i förväg tidigare - mer att testa? Testar vi något som redan testas? Har vi skrivit testfallet på fel sätt Kan vara OK - fyller i tester som saknas etc. 21

2. Få igenom tesfallet Red 2. Make test succeed Failure Green Implement code Error Compile OK Run test success 22

Fokusera på att få igenom testfallet Om vi kommer på fler saker som borde göras: nytt testfall förbättrad design Skriv upp dem på ToDo-listan istället för att ta i dem med en gång minimera tiden med rött ljus, osäkerhet lättare att arbete fokuserat och inte missa detaljer lättare debugga då endast en sak ändrats lättare att hela tiden känna att man kommer framåt. 23

Efter att vi fått igenom ett nytt testfall Reflektera blev helheten bra? har vi bra namn på: klasser, metoder, variabler? Har vi råkat få duplicerad kod? Refaktorisera där det behövs. 24

3. Refaktorisera Red 2. Make test succeed Error Failure Green Implement code Complie OK Run test success Green 3. Refactor Error Failure Green Refactor code Complie OK Run test success 25

Dags att integrera! Nu har vi: implementerat och testat ny funktionalitet refaktoriserat till en enkel och tydlig design grönt ljus - 100% av existerande enhetstester fungerar Villkor för att integrera med gemensamma repositoriet: 1. All kod kompilerar utan felmeddelanden 2. Alla enhetstester går igenom 3. Vår version baserad på senaste i repositoriet! 26

Terminologi Download changes svn: update git: pull Upload changes svn: commit git: commit+push 27

4. Integrera ändringar Red 2. Make test succeed Error Failure Green Implement code Complie OK Run test success Green 4. Integrate Changes Resolve conflict Green b. Automatic merge Download Changes c. Merge conflict a. No merge needed Upload Changes success a. Inga andra Upload sedan vi gjorde Download förra gången b. Inga ändringar i samma filer c. Ändringar i samma filer 28

TestFirst 1. Create new test-case Skapa ett nytt testfall 2. Make test succeed Implementera tills testfallen går igenom Merge Error Failure 4. Integrate changes Download, Merge, Upload 3. Refactor Förbättra design och kod 29

Fördelar med Test First Testfallen driver utvecklingen framåt (blir en agenda) Hjälper oss fokusera på en sak i taget Hjälper oss minimera den tid programmet inte fungerar När något testfall slutar fungera beror det på våra senaste ändringar Underlättar implementation av testfallen All kod blir faktiskt testad (coverage) Test first lättare än Test last - Enklare anpassa produktionskod till testerna än tvärt om! Underlättar design Test first testar även gränssnitten till klasserna - blir bättre Testerna fungera som säkerhetsnät - vi vågar ändra koden och vi vågar förbättra designen. 30

B) Parprogrammering Två personer vid samma maskin Driver och Partner Båda är aktiva Ständig kommunikation Roller växlas ofta All produktionskod skrivs i par Omedelbar kodgranskning Inte nödvändigt vid spikes och acceptanstest Par ändras ofta: Många/alla får insikt i alla delar av koden Nya medarbetare har lättare för komma in i projektet 31

Två roller Driver (Förare) Skriver kod Väljer strategi (i samråd) Beskriver sina intentioner för partnern Partner (Navigator) Granskar kod Ger feedback på design, metodnamn Följer samma strategi som föraren Håller ordning på ToDo-listan 32

Parprogrammeringstips Byt partner ofta! Tacka alltid ja när du blir tillfrågad Tala i Vi-termer i stället för Du: Borde vi inte göra så här i stället? Tala i Jag-termer när det blir krångligt: Jag förstår inte, kan du förklara? 33

Parprogrammeringstips (2) Driver Var lyhörd inför din partner Rusa inte iväg utan beskriv dina idéer Partner Hitta förarens rytm Föreslå rollbyte om ni kör fast,, men ge föraren en chans att fullfölja. 34

Goda programmeringsvanor Ta pauser Man blir trött av parprogramering Ta korta pauser då och då, när ni integrerat, när ett test gått igenom, en gång i timmen. Ödmjukhet Egoless programming - ni programmerar för teamet Ta tillfället att lära dig och att lära ut Ha självförtroende Var inte rädd - din partner är där för att hjälpa dig Din partner vet inte alltid bättre än du. 35

Goda vanor Kommunicera/Lyssna Förare - berätta hela tiden vad du tänker: vi behöver en temporär variabel för iterationen Partner - fråga, kommentera, se till att du hänger med på vad som sker. Föreslå förbättringar. Var en team player Driver och Partner är gemensamt ansvariga för koden Uppstår en bugg eller dålig design - skyll inte på den andre. Hjälps åt att lösa problemet. När något går bra - ta åt er äran tillsammans! 36

Mer om testning 37

Fördelar med automatiserad testning Säkerhetsnät vid ändringar: Man vågar lägga till ny funktionalitet på rätt plats snarare än som ryggsäckar Man vågar förbättra designen refactoring - ändra kod/design Man vågar rätta buggar snarare än koda runt dem 38

Mock objects Hur testar man klasser som behöver en omgivning? - komplicerad, kanske inte implementerad ännu? Skapa en dummy - ett Mock object - för det som saknas. Konfigureras på något sätt TestBankAccount void testxsome() BankAccount void xsome(sek) SecurityMock boolean Verify( ) 39

Self shunt Hur testar man att ett objekt anropar ett klientobjekt på rätt sätt? Skapa ett mock-objekt för klienten Använd testklassen själv som mock-objekt Koden för att starta förloppet att fånga anropet hamnar tillsammans Kräver att mock-objektet anropas via interface. TestBankAccount void testxsome() verify( ) BankAccount void xsome(sek) 40

Testning av interaktiva tillämpningar - GUI Använd MVC - isolera Modellen från Interaktion (View) Gör View-lagret så tunt som möjligt Modellen kan testas med automatiserade tester. GUI GUI GUI GUI Test Test Test Test 41

Hur mycket skall man testa? Testningsstrategi Identifiera typiska fall Testa randvärden (-1, 0, 1, maxint, null, length) Testa all kod (test coverage) XP: Test everything that could possibly break Hur stor del av koden är testkod? Beror på tillämpningen Runt hälften är en vanlig siffra 42

Hierarkiska tester Enhetstester Om en klass kan testas isolerat är det lättare att isolera vad som går fel. Vid behov: koda upp mock objects för att simulera interaktion med andra klasser (för komplexa, finns inte ännu, ) Modultester, subsystemtester Går utmärkt att automatisera med JUnit de också Ersätter inte enhetstester 43

Acceptanstester Kunden Tänker ut ett antal testfall för varje Story Vad kan övertyga mig om att denna Story är implementerad? Kan vara riktiga testdata, t ex från tidigare verksamhet Projektledning Acceptanstesterna mäter hur projektet framskrider Utvecklarna Hjälper kunden implementera acceptanstesterna Automatiserar så mycket som möjligt Acceptanstesterna kan utvecklas parallellt med produktionskoden Kan utvecklas av enskild programmerare 44

Litteratur Kent Beck: Test-driven Development by example. Addison-Wesley. 2003 Bill Wake s site: http://www.xp.123.com/xplor The Test-First Stoplight The Test/Code Cycle in XP 45

Förberedelser Lab 3: Testning och Parprogrammering Lab exercise. Test First using the JUint Testing framework Using JUnit in EDA260 F04 - föreläsningsbilder (dessa) Laurie Williams and Robert Kessler: Pair Programming Illuminated, Addison-Wesley, 2003, Utdrag: delar av kap 1 (Introduction, p 3-5) + kap 27 (Seven Habits of Effective PairProgramming) William C. Wake. Extreme programming Explored, Addison- Wesley, 2002. Utdrag: delar av kap. 1 (How Do You Write a Program?, p 2-10 + 20-21). Chromatic: delar av Part II: p25-32 (Adopt Test-driven Development, Practice Pair Programming) 46

XP:s Deltekniker (Practices) 1. Planering Planeringsspelet Regelbundna releaser Hållbart tempo Kund i teamet 2. Utveckling Test-driven utveckling (TDD) Parprogrammering Kollektivt ägande Kontinuerlig integration 3. Kodning och Design Enkel design Refaktorisering Kodningsstandard Gemensam vokabulär 4. Dessutom Gemensamt utvecklingsrum Nollte iterationen Spikes 52