• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Linux Day 20091024 Test Driven Development
 

Linux Day 20091024 Test Driven Development

on

  • 560 views

 

Statistics

Views

Total Views
560
Views on SlideShare
559
Embed Views
1

Actions

Likes
2
Downloads
4
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Linux Day 20091024 Test Driven Development Linux Day 20091024 Test Driven Development Presentation Transcript

    • Breve introduzione al Test Driven Development Roberto Albertini [email_address] http://www.sourcesense.it/it/agile/team http://www.xpug.it http://www.lugcr.it http://www.linuxday.it
    • Test Driven Development “ Write new code only if an automated test has failed ” Kent Beck
    • Test Driven Development “ Only ever write code to fix a failing test ” Lasse Koskela
    • Test Driven Development “ we produce well-designed, well-tested, and well-factored code in small, verifiable steps ” James Shore
    • i passi del TDD RED GREEN REFACTOR Write a test Make it run Make it right Test Code Design passi piccoli, incrementali, automatizzati
    • W rite a test: RED Scrivi un piccolo unit test che non passa o non compila il test racconta una funzionalità oppure dimostra un baco
    • cos'è uno Unit Test è un Test codice che verifica il funzionamento di altro codice è Unitario di una sola “unità” di codice senza interazioni con altre “unità” o sistemi esterni
    • un buon test è automatizzato e ripetibile un solo click per lanciare tutti i test l'output è consistente output semplice: verde o rosso verifica da solo l'output output “verboso” solo quando è ross o
    • Make it run: GREEN scrivi una semplice implementazione che faccia passare il test L’implementazione deve essere la soluzione più rapida e semplice , anche banale. l’obiettivo è avere i test verdi il prima possibile.
    • Make it right: REFACTOR elimina gli smell migliora il design Questa è l'attività che prende la maggior parte del tempo. Si fa refactor sia del codice di produzione sia del codice di test.
    • Refactor “ Eliminate all of the duplication created in merely getting the test to work ” Kent Beck
    • Refactor “ ...is about transforming the current design toward a better design ” Lasse Koskela
    • Cos'è il Refactoring? “ Is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure ” Martin Fowler
    • Cos'è il Refactoring? migliorare il design del codice esistente senza correre rischi riscivere il codice non è fare refactoring esempio di alcuni passi: Extract method, Move method, Inline method, Extract Class, Introduce Parametr Object, Replace temp with query, Replace conditional with polymorphism
    • Cos'è il Refactoring? miglioramenti a piccoli passi senza “rompere” l'esistente riscivere il codice non è fare refactoring aggiungere/modificare funzionalità non è fare refactoring esempio di alcuni passi: Extract method, Move method, Inline method, Extract Class, Introduce Parametr Object, Replace temp with query, Replace conditional with polymorphism
    • Cosa sono i code smell? sintomi e indizi di qualcosa che “non va” nel codice esempio di alcuni smell duplicazioni, magic number, comenti sospetti, metodi lunghi, feautre envy, lunghe liste di parametri, inappropriate intimacy, message chain, data clump
    • Test Driven Development RED GREEN REFACTOR Write a test Make it run Make it right Test Code Design Ripetere ogni pochi minuti
    • Test Driven Development RED GREEN REFACTOR Ogni 2-10 minuti
    • Test Driven Development è uno stile di sviluppo è una attività di design non è una attività di testing codice testabile decisioni di design poco alla volta prospettiva corretta nel disegnare le api focus sull'obiettivo
    • i Test non sono lo scopo sono lo strumento pongono nella corretta prospettiva aiutano a scomporre i problemi e isolarli aiutano a individuare gli errori con cicli brevi di feedback e sono un utile prodotto “di scarto” rimangono come rete di sicurezza efficacie e duratura
    • un esempio
    • Punteggio del Bowling
    • Frame in una partita si giocano 10 frame in ogni frame si hanno a disposizione 2 tiri per abbattere i 10 birilli
    • Punti in un Frame in ogni frame si prende un punto per ogni birillo abbattuto Esempi 0+0 = segna 0 punti 6+3 = segna 9 punti 3+1 = segna 4 punti
    • Frame con Spare se in un frame con i due si abbattono tutti i 10 birilli si prende un punto bonus per ogni birillo abbattuto nel tiro successivo Esempi Tiro 1 e 9 seguito da 3 e 4 -> 13 punti seguiti da 7 punti Tiro 6 e 4 seguito da 4 e 0 -> 14 punti seguiti da 4 punti Tiro 6 e 4 seguito da 0 e 4 -> 10 punti seguiti da 4 punti
    • Frame con Strike se in un frame con il primo tiro si abbattono tutti i 10 birilli non si fa il secondo tiro e si riceve un punto bonus per ogni birillo abbattuto nei due tiri successivi Esempi Tiro 10, poi 3 e 4 -> 17 punti, poi 7 punti Tiro 10, poi 0 e 4 -> 14 punti, poi 4 punti Tiro 10, poi 10, poi 2+3 -> 22 punti, poi 15 punti, poi 5 punti
    • Ultimo frame se all'ultimo frame ottengo uno spare o uno strike faccio i tiri necessari ad ottenere i bonus Esempio All'ultimo frame tiro 3+7, tiro bonus 4 -> 14 punti All'ultimo frame tiro 10, tiri bonus 3 e 4 -> 17 punti All'ultimo frame tiro 10, tiri bonus 10 e 10 -> 30 punti
    • kata http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata