TDD a piccoli passi
Download as PPTX, PDF2 likes1,182 views
The document discusses test-driven development (TDD) and the three laws of TDD. It begins with the author explaining their initial experiences with TDD and some challenges they faced. It then presents the three laws of TDD which state that you must write a failing test before production code, only write enough test code to fail, and only write enough production code to pass the test. The document provides examples of using TDD with small steps and emphasizes writing one test at a time and improving the code base. It concludes by inviting the reader to try TDD and provides some additional resources on transformations and the transformation priority premise.
TDD a piccoli passi
- 2. All’inizio le mie applicazioni le testavo così...
- 3. Vediamo un po’ come funziona...
- 4. mmm, pensavo fosse meno complicato...
- 5. Ho capito, devo usare i mock!
- 6. Sì, ma che fatica!
- 7. Driven!!
- 8. Cos’è TDD? Scrivi dei test Scrivi codice fino a farli passare tutti Fai un po’ di pulizia
- 9. The Three Laws of TDD 1. “You aren’t allowed to write any production code until you have written a failing unit test”. 2. “You aren’t allowed to write more of a unit test than is sufficient to fail. And not compiling is failing.” 3. “You aren’t allowed to write more production code than is sufficient to pass the currently failing unit test.”
- 10. Ecco cos’è TDD! Write a single test that fails Write code to make the test pass Improve the code base
- 11. The Three Laws of TDD 1. “You aren’t allowed to write any production code until you have written a failing unit test”. 2.“You aren’t allowed to write more of a unit test than is sufficient to fail. And not compiling is failing.” 3. “You aren’t allowed to write more production code than is sufficient to pass the currently failing unit test.”
- 12. Proviamoci! See the code on Github: https://github.com/jesuswasrasta/SmallStepsTDD.git
- 13. • Nell’algoritmo non v’è espresso il concetto di numero primo • Brainlessness (2 -> n) • I cicli sono una generalizzazione delle if • Passo dei test nuovi senza modificare codice • Se immaginiamo i test come feature, che bello sarebbe aggiungere funzionalità al nostro software con questa facilità?! • Refactoring: rimuovere duplicazione, rimuovere codice Cosa si nota?
- 14. ({}–>nil) no code at all->code that employs nil (nil->constant) (constant->constant+) a simple constant to a more complex constant (constant->scalar) replacing a constant with a variable or an argument (statement->statements) adding more unconditional statements. (unconditional->if) splitting the execution path (scalar->array) (array->container) (statement->recursion) (if->while) (expression->function) replacing an expression with a function or algorithm (variable->assignment) replacing the value of a variable. Transformations
Editor's Notes
- #2: Sentito parlare di TDD grazie ai colleghi Esistono strumenti per testare il proprio codice Volgio imparare ad usarli! Anche perché all’inzio I test…
- #3: i test li facevo così all’epoca mi occupavo di un software che interfacciava gestionale con tanti servizi e dispositivi esterni come faccio a scovare i bug prima del rilascio? prima riflessione: posso mica migliorare?
- #4: Impara ad usare un framework di test Fai qualche kata Ok, fatto!
- #5: Inizio test in produzione difficoltà di aggiungere test a codice esistente testare oggetti complessi come costruisco e soddisfo le dipendenze?
- #6: oggetti complessi e tante dipendenze? Le soddisfo coi mock imapara framerwork di mock
- #7: Impiegare 10 minuti per implementare un metodo e 3 ore per testarlo! mocki l’impossibile, ma alla fine che cosa testi che è tutto finto?! Sarà mica così che funziona? E’ ora di fare un’altra riflessione...
- #8: I test li devi scrivere prima, l’hai capito o no?! Si, lo facevo, ma proprio smepre sempre «Per le cose semplici non serve TDD»
- #9: Pr me TDD era così Facevo un TDD «alla buona»
- #10: scopro solid principles leggo un paio di libri, leggo zio bob, Scopro 3 laws of TDD
- #13: Kata
- #14: il codice come una sequenza di trasformazioni, di complessità incrementale
- #15: il codice come una sequenza di trasformazioni, di complessità incrementale
- #16: il codice come una sequenza di trasformazioni, di complessità incrementale