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

TDD: An experience report

TDD: An experience report

TDD: An experience report

Presented over at Bangalore Ruby meetup, December 2020 https://www.airmeet.com/e/d3021470-2e12-11eb-9d2e-9bc52c66b921

Talks about Test Driven Development (TDD) and the experiences around it in projects where it was followed and where it wasn't followed and notes around it.

Tasdik Rahman

December 03, 2020
Tweet

More Decks by Tasdik Rahman

Other Decks in Programming

Transcript

  1. TDD: An experience report
    tasdikrahman.me || @tasdikrahman

    View Slide

  2. tasdikrahman.me || @tasdikrahman

    View Slide

  3. ● Software Engineer @ Gojek (Engg Platform)
    ● Formerly, #4 in the cloud infra team @ Razorpay
    ● Past contributor to oVirt
    ● Backpacker
    ● Chelsea FC!!
    tasdikrahman.me || @tasdikrahman

    View Slide

  4. Side projects
    Image credits: wikipedia

    View Slide

  5. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem

    View Slide

  6. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready

    View Slide

  7. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready
    Share with
    friends/twitter/reddit

    View Slide

  8. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready
    Share with
    friends/twitter/reddit
    People start using
    it/give reviews.

    View Slide

  9. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready
    Share with
    friends/twitter/reddit
    People start using
    it/give reviews.
    Profit(?)/
    Would that be it? X days/weeks
    elapsed

    View Slide

  10. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready
    Share with
    friends/twitter/reddit
    People start using
    it/give reviews.
    If the project got
    traction, usually it’s
    NO X days/weeks
    elapsed

    View Slide

  11. Side projects
    Come across foo
    problem/
    itch for solving some
    foo problem
    Have an MVP ready
    Share with
    friends/twitter/reddit
    People start using
    it/give reviews.
    Bug reports/
    Issues for feature
    additions/
    PR’s added to be
    merged
    X days/weeks
    elapsed

    View Slide

  12. Quick Detour for an example

    View Slide

  13. Example?
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  14. Things to note in this
    example
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  15. Has no tests at all!
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  16. Has been some time since it
    has had any contributions
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  17. Bug Reports
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  18. Bug Reports
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  19. Bug Reports
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  20. Bug Reports
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  21. Bug Reports
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  22. Stale PRs
    Link: https://github.com/tasdikrahman/tnote

    View Slide

  23. So what happened here

    View Slide

  24. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken

    View Slide

  25. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Lot’s of manual
    testing for fixing a
    bug/merging a PR

    View Slide

  26. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Lot’s of manual
    testing for fixing a
    bug/merging a PR
    Resistance for
    testing while fixing a
    bug/adding a
    feature

    View Slide

  27. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Lot’s of manual
    testing for fixing a
    bug/merging a PR
    Resistance for
    testing while fixing a
    bug/adding a
    feature
    Anti-patterns

    View Slide

  28. Time for another example

    View Slide

  29. Time for another example
    Link: https://github.com/tasdikrahman/bhola/

    View Slide

  30. What was done differently?

    View Slide

  31. TDD for a change
    1st PR for the project:
    https://github.com/tasdikrahman/bhola/pull/5

    View Slide

  32. TDD?

    View Slide

  33. TDD?
    Red
    Green
    Refactor

    View Slide

  34. TDD?
    Write a spec,
    get it to fail
    Make it pass/
    implement
    the spec
    Refactor/
    remove
    duplication

    View Slide

  35. Baby steps

    View Slide

  36. Breaking problem into
    multiple steps

    View Slide

  37. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Specs double up as
    documentation
    Test Coverage as a
    by product
    Design by contract

    View Slide

  38. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Lot’s of manual
    testing for fixing a
    bug/merging a PR
    Specs double up as
    documentation
    Passing specs increase
    confidence that x
    bugfix/feature doesn’t
    break existing
    functionality
    Test Coverage as a
    by product
    Design by contract Testable code Anti-patterns

    View Slide

  39. So what happened here
    Context lost over
    time/forgot why x
    decision was
    taken/not taken
    Lot’s of manual
    testing for fixing a
    bug/merging a PR
    Resistance for
    testing while fixing a
    bug/adding a
    feature
    Anti-patterns
    Specs double up as
    documentation
    Passing specs increase
    confidence that x
    bugfix/feature doesn’t
    break existing
    functionality
    Refactor fearlessly as
    domain changes/new
    features get planned
    Test Coverage as a
    by product
    Design by contract Testable code

    View Slide

  40. Is 100% coverage gonna
    provide bug free software?

    View Slide

  41. No

    View Slide

  42. Quick example from the
    same project

    View Slide

  43. Relevant PR: https://github.com/tasdikrahman/bhola/pull/65
    Wrong value being stubbed

    View Slide

  44. Bugs even
    though it
    had 99.4%
    coverage

    View Slide

  45. Undesirable Side effects of
    high code coverage

    View Slide

  46. Undesirable Side effects of
    high code coverage
    Needs maintenance
    similar to production
    codebase

    View Slide

  47. Undesirable Side effects of
    high code coverage
    Needs maintenance
    similar to production
    codebase
    Can quickly become a
    bunch of unused tests
    if not removed as and
    when domain changes

    View Slide

  48. Undesirable Side effects of
    high code coverage
    Needs maintenance
    similar to production
    codebase
    Can quickly become a
    bunch of unused tests
    if not removed as and
    when domain changes
    Time as cost incurred
    while developing a
    feature

    View Slide

  49. Is TDD the silver bullet?

    View Slide

  50. No

    View Slide

  51. Where would I think of not
    practicing TDD?

    View Slide

  52. Where would I think of not
    practicing TDD?
    While scripting
    something quick

    View Slide

  53. Where would I think of not
    practicing TDD?
    While scripting
    something quick
    When the interface is
    loose/changing too fast

    View Slide

  54. Some other ways to have
    more confidence in your
    codebase

    View Slide

  55. Some other ways to have more
    confidence in your codebase
    Robust and extensive
    E2E testing (preferably
    automated)

    View Slide

  56. Some other ways to have more
    confidence in your codebase
    Robust and extensive
    E2E testing (preferably
    automated)
    Type system

    View Slide

  57. Some other ways to have more
    confidence in your codebase
    Robust and extensive
    E2E testing (preferably
    automated)
    Type system Documentation

    View Slide

  58. Some other ways to have more
    confidence in your codebase
    Robust and extensive
    E2E testing (preferably
    automated)
    Type system Documentation
    Fuzzy testing (apart
    from oracle tests)

    View Slide

  59. The only real test is when your software is getting
    used by someone. This is where it should
    behave/perform as it is expected out of it.

    View Slide

  60. tasdikrahman.me || @tasdikrahman

    View Slide