tdd.every.where.21012012

21
«Non c'è uomo che non possa bere o mangiare ma, sono in pochi in grado di capire che cosa abbia sapore.» Confucio Agenda «Gli aforismi riassumono il mondo.» Me TDD What? Why? Where? Pro/Cons Feature Driven Development Agile XP TDD Pair programming Pomodoro

Upload: matteo-migliore

Post on 21-May-2015

572 views

Category:

Documents


2 download

TRANSCRIPT

  • 1. Agenda Gli aforismi riassumono il mondo. Me TDD What? Why? Where? Pro/Cons Feature Driven Development Agile XP TDD Pair programming PomodoroNon c uomo che non possa bere o mangiare ma,sono in pochi in grado di capire che cosa abbia sapore. Confucio

2. What?TestDrivenDDevelopment DesignFeatureNon esiste vento favorevole per il marinaio senza rotta. Seneca 3. 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 attivitproduttive 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 4. What?Testing lifecycleTestRefactor CodeSono le minoranze di entusiasti a fare la storia, per poi imporla ai pigri e agli scettici. M. Gramel 5. What?1. Il codice non esiste, prima il test[TestMethod]public void CalculateDivision(){var division = new Division (); ////The class Division notexist} 6. 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);}} 7. 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);}} 8. 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);} 9. 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);} 10. 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);} 11. 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 unimpresa titanica!Il refactoring lattivit sul codice che ne mantiene invariato laspettofunzionale migliorando la manutenibilit. E fondamentale seguire il ciclo sopradescritto e continuare a semplificiare e spezzare secondo il Single Point of 12. 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 formicaSiiiiii... la palla!. da Z la formica 13. Why?I test sono un piacevole side effect di TDD, ma non sono il goal principale.La robustezza dellapplicazione data da molti fattori, tra i qualiunarchitettura 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 14. Why?//Comments are unuseful!var value = "The fox is near the window.";var characterList = new List();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. 15. Why?MakeMethodsNotWar();RemoveNumbersMakeToUpperAndReverse("The fox is near the window.);Raise your hand when you understand what the code does. 16. 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. 17. Where? Unit test Integration testGli integration test sono particolari tipi di unit test che lavorano su classi diproduzione, verificando la correttezza di parti dellapplicazione che sarannodavvero in gioco.Sono complessi da manutenere e scrivere, ma sono le vere basi del software.- Benchmark- Long times operations- components orchestration 18. 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: ContinuosIntegrationAspira a migliorare il mondo per migliorare davvero te stesso. Me 19. FeatureDrivenDevelopmentNulla pi facile che illudersi. Perch luomo crede vero ci che desidera. Demostene 20. RingraziamentiA mia moglie, che sopporta EveryThingAdper avermi permesso di ultimare le slide 21. To be continued...More slides have to come on this TDD session.