Tdd.Every.Where.21012012
Upcoming SlideShare
Loading in...5
×
 

Tdd.Every.Where.21012012

on

  • 626 views

 

Statistics

Views

Total Views
626
Views on SlideShare
626
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

Tdd.Every.Where.21012012 Tdd.Every.Where.21012012 Presentation Transcript

  • Agenda• «Gli aforismi riassumono il mondo.» Me• TDD • What? • Why? • Where? • Pro/Cons• Feature Driven Development• Agile • XP • TDD • Pair programming • Pomodoro «Non cè uomo che non possa bere o mangiare ma, sono in pochi in grado di capire che cosa abbia sapore.» Confucio
  • What?Test Driven D Development Design Feature«Non esiste vento favorevole per il marinaio senza rotta.» Seneca
  • What?TDD è una tecnica agile che consente di focalizzarci sulla funzionalità ed ildesign, quindi sul cosa, non sul come.Scrivere il test prima del codice è una scorciatoia molto efficace per produrresoluzioni di qualità e un software di successo.Se «nella vita è importante il percorso e non la meta» nel caso delle attivitàproduttive è vero il contrario, quindi «il fine giustifica i mezzi», nella suaaccezione più positiva, è la filosofia con cui questa metodologia di svilupposi è imposta come alternativa negli ultimi anni. «Cominciate col fare ciò che è necessario, poi ciò che è possibile. E allimprovviso vi sorprenderete a fare limpossibile.» San Francesco
  • What?Testing lifecycle Test Refactor Code«Sono le minoranze di entusiasti a fare la storia, per poi imporla ai pigri e agli scettici.» M. Gramel
  • What?1. Il «codice» non esiste, prima il test[TestMethod]public void CalculateDivision(){ var division = new Division (); ////The class Division notexist}
  • What?2. Il test inizialmente deve fallire[TestMethod] public class Divisionpublic void DivideTwoPositiveNumbers() {{ public int Calculate(int a, int b) new Division() { .Calculate(6, 2) throw new NotImplementedException(); .Should(«The division failed.») } .Be.EqualTo(3); }}
  • What?3. Tendenzialmente è bene supportare solo gli use-case necessari[TestMethod] public class Divisionpublic void DivideTwoPositiveNumbers() {{ public int Calculate(int a, int b) new Division() { .Calculate(6, 2) return 3; .Should(«The division failed.») } .Be.EqualTo(3); }}
  • What?4. Seguire il ciclo test-code-refectator e «no duplication»[TestMethod] public class Divisionpublic void DivideTwoPositiveNumbers() {{ public int Calculate(int a, int b) CalculateAndCheck(6, 2, 4); {} return a / b; }[TestMethod] }public voidDivideANumberByOneMustReturnTheNumber(){ CalculateAndCheck(6, 1, 6);}private void CalculateAndCheck(int a, int b, intexpected){ new Division() .Calculate(a, b) .Should(«The division failed.») .Be.EqualTo(expected);}
  • What?5. Code coverage: 100% non significa codice privo di bug[TestMethod] public class Divisionpublic void DivideANumberByZero() {{ public int Calculate(int a, int b) //This inputs breaks the code but { //the code coverage is 100% return a / b; CalculateAndCheck(6, 0, ?); }} }private void CalculateAndCheck(int a, int b, intexpected){ new Division() .Calculate(a, b) .Should(«The division failed.») .Be.EqualTo(expected);}
  • What?6. Bug fixing: bug - test - fix[TestMethod] public class Division[ExpectedException(typeof(DivideByZeroException) {] public double Calculate(int a, int b)public void {DivideANumberByZeroThrowsException() return a / b;{ } //This inputs breaks the code but } //the code coverage is 100% CalculateAndCheck(6, 0, double.NaN);}private void CalculateAndCheck(int a, int b, doubleexpected){ new Division() .Calculate(a, b) .Should(«The division failed.») .Be.EqualTo(expected);}
  • What?Il codice di test ha pari dignità del codice applicativo. Il codice di test è codiceapplicativo.Va manutenuto, il refactoring è lo strumento da utilizzare.La duplicazione è il male assoluto: never duplicate.Ancora più importante del KISS («Keep it short and simple», in originale «Keepit Simple, Stupid!») principle.Se il codice è complesso ma centralizzato, il refactoring è applicabile in modopiuttosto efficiente.Se il codice, anche semplice, è duplicato in molti punti, correggerlo emigliorarlo diventa un’impresa titanica!Il refactoring è l’attività sul codice che ne mantiene invariato l’aspettofunzionale migliorando la manutenibilità. E’ fondamentale seguire il ciclo sopradescritto e continuare a semplificiare e «spezzare» secondo il Single Point of
  • Why?La complessità del sistema è maggiore della somma della complessità dellesingole parti.TDD consente di continuare a «spezzare» le singole parti, renderle testabili equindi maggiormente affidabili. Z la formica «Siiiiii... la palla!.» da «Z la formica»
  • Why?I «test» sono un piacevole side effect di TDD, ma non sono il goal principale.La robustezza dell’applicazione è data da molti fattori, tra i qualiun’architettura semplice.Scrivere meno codice possibile. Meno codice, statisticamente meno bug.Aumentare la leggibilità: usare la tecnica di refactoring «extract method» amanetta! «La semplicità è la forma della vera grandezza.» Francesco De Sanctis
  • Why?//<ironic>Comments are unuseful!</ironic>var value = "The fox is near the window.";var characterList = new List<char>();foreach (var c in value){ if (c< ‘0’ || c> ‘9’) { characterList.Add(char.ToUpper(c)); }}characterList.Reverse();var ret = new string(characterList.ToArray());Raise your hand when you understand what the code does.
  • Why?MakeMethodsNotWar();RemoveNumbersMakeToUpperAndReverse(«"The fox is near the window.“);Raise your hand when you understand what the code does.
  • Where?• Unit test• Integration testGli unit test consentono di definire il design di «unit» di codice, cioè classi.Hanno la caratteristica di non usare risorse lente (IO, DB, servizi, device),devono essere eseguiti costantemente, ad ogni modifica del codice e nel modopiù veloce possibile. Devono essere istantanei.
  • Where?• Unit test• Integration testGli integration test sono particolari tipi di unit test che lavorano su classi diproduzione, verificando la correttezza di parti dell’applicazione che saranno«davvero in gioco».Sono complessi da manutenere e scrivere, ma sono le vere basi del software.- Benchmark- Long times operations- components orchestration
  • Where?Where? Check again the session title!Fight the «we are different syndrome»!Alcuni esempi «estremi» a cui applicare TDD:- gaming: BomberMan- vision: Motion Detector- hardware interaction: SerialPort- TFS and MSBuild: ContinuosIntegration «Aspira a migliorare il mondo per migliorare davvero te stesso.» Me
  • Feature Driven Development«Nulla è più facile che illudersi. Perché luomo crede vero ciò che desidera.» Demostene
  • RingraziamentiA mia moglie, che sopporta «EveryThing»Ad per avermi permesso di ultimare le slide
  • To be continued...More slides have to come on this TDD session.