tdd workshop

tdd workshop

A workshop on test-driven development presented during Tryst 2013, an annual science and technology festival at IIT Delhi.

E2143258b0228b454fa4b63d406243f3?s=128

Avinash Chugh

March 02, 2013
Tweet

Transcript

  1. test-driven development why do cars have brakes?

  2. At the end of this workshop... Build production quality software

    Experience unit testing Appreciate good design principles Gain insights Taking it further
  3. None
  4. “One broken window, left unrepaired for any substantial length of

    time, instills in the inhabitants of the building a sense of abandonment – a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.” The Pragmatic Programmer
  5. “Legacy code is code without tests.” Michael Feathers, 2002

  6. code inspection only take you so far...

  7. A software development technique in which automated tests are written

    iteratively alongside the production code TDD
  8. A software development technique in which automated tests are written

    iteratively alongside the production code TDD
  9. A software development technique in which automated tests are written

    iteratively alongside the production code TDD
  10. A software development technique in which automated tests are written

    iteratively alongside the production code TDD
  11. “But one should not first make the program and then

    prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.” The Humble Programmer, Edsger W. Dijkstra 1972
  12. No excuses Avoid “we’re too busy” Defer “let QA test

    the software” Deny “we don’t have bugs” Play dumb “we don’t know how”
  13. Three simple rules You can’t write production code unless it

    makes a failing unit test pass. Rule 1
  14. Three simple rules You can’t write any more of unit

    test that is sufficient to fail, and not compiling is failing. Rule 2
  15. Three simple rules You can’t write any more production code

    than is sufficient to pass one failing unit test. Rule 3
  16. the development lifecycle

  17. half-adder circuit

  18. Core entities Wire Inverter OrGate AndGate Probe

  19. Courage Introduce change Refactor Evolve the design

  20. Feedback Improves your design Shows how it works Tells you

    when done
  21. TDD doesn't drive good design. TDD gives you immediate feedback

    about what is likely to be bad design. -Kent Beck
  22. Simplicity Clean code Simple design Evolution

  23. Communication Documents behavior Reveals intent Tells you when things stop

    working
  24. Good unit tests are... Fast Isolated Repeatable Self-validating Timely

  25. “Brakes allow you to travel faster because you have the

    power to stop.” So why do cars have brakes?
  26. suggested reading