Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Test-Driven Development

Test-Driven Development

A presentation on TDD as I was presenting it in 2008.

Matteo Vaccari

June 03, 2008
Tweet

More Decks by Matteo Vaccari

Other Decks in Technology

Transcript

  1. Matteo Vaccari [email protected] http://matteo.vaccari.name/blog BIt Systems, 4 June 2008 Test-Driven

    Development
  2. Three kinds of test • Unit test • Integration test

    • Customer test
  3. Unit tests • Focus on a class, method or function

    • Run entirely in memory • Extremely fast!
  4. Unit tests run fast. A test is not a unit

    test if: 1. It talks to a database 2. It communicates across the network 3. It touches the file system 4. You have to do things to your environment to run it (eg, change config files) Tests that do this are integration tests Michael Feathers
  5. Integration tests • Unit tests prove our logic is correct

    • Integration test prove our program communicates correctly with the outside world
  6. System under test DB Billing GUI End-to-end tests

  7. System under test DB Billing GUI End-to-end tests • ...are

    the least convenient kind of integration tests
  8. System under test DB Billing GUI Focused integration tests •

    Each test deals with one external interaction
  9. Customer tests • Also known as “Acceptance tests” • Motto:

    We implement tricky domain concepts correctly Example from Mugridge & Cunningham Fit For Developing Software
  10. Customer tests • Customer test are customer-provided examples • Often

    captured in table form • Expressed in the language of the business • Automated Example from Mugridge & Cunningham Fit For Developing Software
  11. None
  12. Test-Driven Development

  13. Clean code that works.

  14. Clean code that works • is out of reach of

    even the best programmers, some of the time, • and out of reach of most programmers (like me) most of the time -- Kent Beck
  15. Simple design The code is simple enough when it: 0.

    Runs all the tests 1. Expresses every idea that we need to express 2. Contains no duplication 3. Has the minimum number of classes and functions (In this order) Adapted from Extreme Programming Installed by Ron Jeffries et al.
  16. Clean code that works • First we'll solve the “that

    works” part • Then we'll solve the “clean code” part
  17. [email protected] Write a test public class AdderTest { @Test public

    void testTwoPlusThree() { Adder a = new Adder(); assertEquals(5, a.add(2, 3)); } }
  18. [email protected] Now it compiles public class AdderTest { @Test public

    void testTwoPlusThree() { Adder a = new Adder(); assertEquals(5, a.add(2, 3)); } } public class Adder { public int add(int a, int b) { return 0; } }
  19. [email protected] Red bar! public class AdderTest { @Test public void

    testTwoPlusThree() { Adder a = new Adder(); assertEquals(5, a.add(2, 3)); } } public class Adder { public int add(int a, int b) { return 0; } } Expected 5, was 0
  20. [email protected] Just pretend public class AdderTest { @Test public void

    testTwoPlusThree() { Adder a = new Adder(); assertEquals(5, a.add(2, 3)); } } public class Adder { public int add(int a, int b) { return 5; } }
  21. [email protected] Remove the duplicated “5” public class AdderTest { @Test

    public void testTwoPlusThree() { Adder a = new Adder(); assertEquals(5, a.add(2, 3)); } } public class Adder { public int add(int a, int b) { return a+b; } }
  22. [email protected] The procedure 1. Write a test 2. Make it

    compile 3. Make it pass 4. Remove duplication Expected 5, was 0
  23. [email protected] Red Green Refactor Repeat every 2-10 min.

  24. [email protected] Clean code, why? • Design is the great accelerator:

    • If you drop quality for speed, you will get neither • If you aim for quality... • ... and you know how to get it... • ... you will also be fast!
  25. [email protected] Test first, why? • You think code from the

    point of view of the caller • This perspective makes for better design • Test coverage is a useful byproduct
  26. [email protected] Refactor, why? • Because I can: the tests support

    refactoring • Refactoring is when I do design • I don’t claim I can guess the right design at first • Design emerges, with thought, care and small steps
  27. [email protected] The Bowling Score By Robert Martin “Uncle Bob” http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

  28. [email protected] Il punteggio del bowling Ci sono 10 frame. In

    ogni frame il giocatore ha due possibilità di abbattere 10 birilli (pins). Il punteggio per il frame è il numero di birilli abbattuti, più i bonus per stike o spare. Uno spare è quando il giocatore abbatte 10 birilli in due tiri. Il bonus per quel frame è il numero di birilli abbattuti al tiro successivo. Nel frame 3 dell'esempio, il punteggio è 10 (i birilli abbattuti) più il bonus di 5 (abbattuti nel tiro successivo.) Uno strike è quando il giocatore abbatte tutti i birilli in un solo tiro. Il bonus per quel frame è il numero di birilli abbattuti nei due tiri successivi Nel decimo frame, se il giocatore fa uno strike o spare può fare i tiri necessari per completare il frame. In ogni caso, al decimo frame non vengono fatti più di tre tiri.
  29. [email protected] The requirements • Write class “Game” with two methods:

    • void roll(int pins); call when the player rolls a ball. The argument is the number of pins knocked down. • int score(); called when the game is ended. Returns the final score.
  30. [email protected] Let’s think about design? • A quick object-oriented analysis

    leads us to think we need • class Game • class Frame • class Roll • class TenthFrame extending Frame • ...
  31. [email protected] Let’s think about design? • A quick object-oriented analysis

    leads us to think we need • class Game • class Frame • class Roll • class TenthFrame extending Frame • ... forget about all that!
  32. [email protected] Demo time • ...eclipse!

  33. [email protected] Ancora, perché test first? • per concentrarsi su quello

    che serve veramente (no gold plating) • good enough! quando il test passa so che posso fermarmi • perché penso al codice come un cliente di questo codice • perché ottengo codice testabile, e il codice testabile • ha uno scopo preciso • è disaccoppiato dal resto del sistema • è più generale • il design emerge mano a mano che capisco meglio il problema
  34. [email protected] Ancora, perché refactoring? • simplicity is key • il

    design nel tempo si imbastardisce • fare il design prima significa farlo nel momento peggiore: quando ne so di meno • molto meglio fare design mentre sviluppo
  35. [email protected] Do the simplest thing that can possibly work

  36. [email protected] Do the simplest thing 1. Build the quickest code

    that will pass the tests 2. Refactor the code to have the simplest design possible
  37. [email protected]sense.com What is simple design? • The code passes all

    tests • There is no duplication • The code expresses the programmer’s intention • Using the smallest number of classes and methods In this order
  38. [email protected] TDD is a key practice • Defects kill predictability

    no predictability, no planning! • Test-driven is predictable • Hardly ever use the debugger
  39. [email protected] No silver bullet • Needs lots of practice •

    Requires discipline • Must think and be alert at all times!
  40. Debugging Sucks Testing Rocks

  41. None
  42. Supermarket checkout • Compute the total price • Scan items

    one at a time • In any order Source: Dave Thomas, http://codekata.pragprog.com/2007/01/kata_nine_back_.html
  43. Back to the supermarket