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

TDD: The Good Parts

Adam Wathan
November 07, 2014

TDD: The Good Parts

Test-driven development can be hard, and a lot of the “rules” can often become a distraction from the real reasons you're writing tests in the first place.

In this talk, you’ll find out what the real benefits of TDD are, what really makes code “good”, and why testability shouldn’t be your only yardstick for measuring code quality.

I’ll also show you some of the pitfalls of a “purist” testing approach, and give you strategies you can use to test-first without sacrificing simplicity or expressiveness in your code.

If you’ve ever given up on testing because it seemed so hard to do everything “by the book”, this talk will feel like a breath of fresh air and give you the tools you need to start writing tests that really matter.

Adam Wathan

November 07, 2014
Tweet

More Decks by Adam Wathan

Other Decks in Programming

Transcript

  1. TDD
    The Good Parts
    @adamwathan

    View full-size slide

  2. Code that's hard to test in
    isolation is poorly designed
    1
    Test Driven Evangelists

    View full-size slide

  3. Isolated testing has given
    birth to some truly
    horrendous monstrosities
    of architecture.
    1
    David Heinemeier Hansson

    View full-size slide

  4. A dense jungle of service
    objects, command patterns,
    and worse.
    1
    David Heinemeier Hansson

    View full-size slide

  5. What makes good code?

    View full-size slide

  6. 1. Easy to change

    View full-size slide

  7. 2. Easy to understand

    View full-size slide

  8. 3. Enjoyable to use

    View full-size slide

  9. What am I doing wrong?!

    View full-size slide

  10. Why test first?

    View full-size slide

  11. 1. Confident refactoring

    View full-size slide

  12. 2. Emphasize public API

    View full-size slide

  13. 3. Identify task at hand

    View full-size slide

  14. Isolation is
    overrated

    View full-size slide

  15. Pitfall #1
    Lying tests

    View full-size slide

  16. Solution #1
    Use real collaborators

    View full-size slide

  17. When your tests use the
    same collaborators as your
    application, they always
    break when they should.
    1
    Sandi Metz

    View full-size slide

  18. The value of this cannot be
    underestimated.
    1
    Sandi Metz

    View full-size slide

  19. Pitfall #2
    Implementation coupling

    View full-size slide

  20. Solution #2
    ... Use real collaborators!

    View full-size slide

  21. The great irony of over-
    isolation is that it actually
    makes you more dependent
    on implementation.
    1
    Steve Fenton

    View full-size slide

  22. Pitfall #3
    The Dreaded "Design Damage"

    View full-size slide

  23. Easy to understand?

    View full-size slide

  24. Enjoyable to use?

    View full-size slide

  25. Easy to unit test?

    View full-size slide

  26. This tests nothing.

    View full-size slide

  27. Solution #3
    FOR THE LOVE OF GOD USE REAL
    COLLABORATORS!!!!

    View full-size slide

  28. If talking to the database
    is stable and fast then
    there's no reason not to do
    it in your unit tests.
    1
    Martin Fowler

    View full-size slide

  29. Testing is an art

    View full-size slide

  30. ...and a Journey

    View full-size slide

  31. Push yourself to learn

    View full-size slide