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.

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