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

Några principer för effektiv enhetstestning

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

Agil programutveckling

F2 XP Extremprogrammering översikt

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

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

Några grundläggande begrepp

XP-projekt: En fördjupning

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

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

Testplanering, test-first, testverktyg

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

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

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

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Visuell GUI Testning

Enhetstester på.netplattformen

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

Kritik av Extrem Programmering

Vad betyder TDD? Test Driven Design?

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

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

Versionshantering. Jan Erik Moström

F6 Arkitektur, Planering

Agil testning i SCRUM

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

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

XP vs. Tillverkningsindustrin

Tentamen. 2D4135 vt 2004 Objektorienterad programmering, design och analys med Java Torsdagen den 3 juni 2004 kl

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

Classes och Interfaces, Objects och References, Initialization

Objektsamlingar i Java

Kvalitetssäkra ditt projekt med kontinuerlig integration

Sammanfattningar Essentials of Software Engineering

Teststrategier och Testcertifiering. Per Strandberg, Maj 2013

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

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

Föreläsning 4 IS1300 Inbyggda system

Proj-Iteration1. Arkitektur alt. 1

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

F6 Objektorienterad design. ID1004 Objektorienterad programmering Fredrik Kilander

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

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

Metoder och verktyg för funktionssäkerhet

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

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

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

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

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

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

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

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Filhanterare med AngularJS

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

12 principer of agile practice (rörlig)

Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola

Programvaruutveckling - Metodik 2016 Jonas Wisbrant

Scrum + XP samt konsekvensanalys

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

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

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

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

Tentamen Programmering fortsättningskurs DIT950

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

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

Linköpings universitet 1

Användarcentrerad systemdesign

Kopiering av objekt i Java

Identitet och ekvivalens

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

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

Tentamen. Programmeringsmetodik, KV: Java och OOP. 17 januari 2002

Verktyg och Utvecklingsmiljö. Jochim von Hacht

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

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

Länkade listor och automatisk testning

Agile-metoder, XP och ACSD

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

Exercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15

ALM Live: Testfokus bättre mjukvarukvalitét med Visual Studio 2008 Team System

Lösningar till tentamen i EDAF25

Design av en klass BankAccount som representerar ett bankkonto

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document

Användarcentrerad systemdesign

Objektorienterad Programmering DAT043. Föreläsning 10 13/2-18 Moa Johansson (delvis baserat på Fredrik Lindblads material)

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

Proj-Iteration 5B. Plan för återstående iterationer

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i.

Tentamen i Objektorienterad modellering och design

Objektorienterad programmering

Föreläsning 3 Verifiering och Validering

UML. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

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

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

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

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 7

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. 8

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 9

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) 10

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()); } 11

junit -verktyget 12

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 13

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 konoutdrag 14

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. 15

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

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. 17

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

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. 19

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. 20

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 21

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! 22

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

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 24

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

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. 26

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 27

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 28

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? 29

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. 30

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. 31

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! 32

Mer om testning 33

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 34

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( ) 35

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) 36

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 37

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 38

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 39

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 40

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 41

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) 42

Extra material om testning Ett enkelt kalkylblad som exempel A B C D E F 1 Beställning 2 Artikel Antal Färg Storlek Styckpris Pris 3 Mössa 1 röd L 99.50 99.50 4 Strumpor 10 blå M 19.50 195.00 5 6 7 Netto: 294.50 8 Frakt: 34.00 9 Brutto: 328.50 43

Exempel på tesfall [Bill Wake, xp123.com/xplor/xp0201] Basic functionality storing values in cells ThatCellsAreEmptyByDefault ThatTextCellsAre Stored ThatManyCellsExist ThatNumericCellsAreIdentifiedAndStored SimpleFormulas ThatWeHaveAccessToCellLiteralValuesForEditing FormulaSpec ConstantFormula Add Dependencies checkthatcellreferencework checkthatcellchangespropagate 44

CheckThatCellsAreEmptyBy Deafult @Test public void checkthatcellsareemptybydefault(){ Sheet sheet = new Sheet(); assertequals( cells are empty,, sheet.get( A1 ) ); assertequals( cells are empty,, sheet.get( ZX347 ) ); } 45

checkthattextcellsarestored @Test public void checkthattextcellsarestored(){ Sheet sheet = new Sheet(); String thecell = A21 ; sheet.put(thecell, A string ); assertequals( cells are stored-1, A string, sheet.get(thecell); sheet.put(thecell, A different string ); assertequals( cells are stored-2, A different string, sheet.get(thecell); sheet.put(thecell, ); assertequals( cells are stored-3,, sheet.get(thecell); } 46

checkthatcellreference- Works @Test public void checkthatcellreferenceworks(){ Sheet sheet = new Sheet(); sheet.put( A1, 8 ); sheet.put( A2, =A1 ); assertequals( cell lookup, 8, sheet.get( A2 ); } 47

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 48