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.

99f99340cf6fe31f86e8dd0a988eec7c?s=128

Tasdik Rahman

December 03, 2020
Tweet

Transcript

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

  2. tasdikrahman.me || @tasdikrahman

  3. • Software Engineer @ Gojek (Engg Platform) • Formerly, #4

    in the cloud infra team @ Razorpay • Past contributor to oVirt • Backpacker • Chelsea FC!! tasdikrahman.me || @tasdikrahman
  4. Side projects Image credits: wikipedia

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

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

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

    foo problem Have an MVP ready Share with friends/twitter/reddit
  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.
  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
  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
  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
  12. Quick Detour for an example

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

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

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

  16. Has been some time since it has had any contributions

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

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

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

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

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

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

  23. So what happened here

  24. So what happened here Context lost over time/forgot why x

    decision was taken/not taken
  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
  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
  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
  28. Time for another example

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

  30. What was done differently?

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

  32. TDD?

  33. TDD? Red Green Refactor

  34. TDD? Write a spec, get it to fail Make it

    pass/ implement the spec Refactor/ remove duplication
  35. Baby steps

  36. Breaking problem into multiple steps

  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
  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
  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
  40. Is 100% coverage gonna provide bug free software?

  41. No

  42. Quick example from the same project

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

  44. Bugs even though it had 99.4% coverage

  45. Undesirable Side effects of high code coverage

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

    to production codebase
  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
  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
  49. Is TDD the silver bullet?

  50. No

  51. Where would I think of not practicing TDD?

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

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

    something quick When the interface is loose/changing too fast
  54. Some other ways to have more confidence in your codebase

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

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

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

    Robust and extensive E2E testing (preferably automated) Type system Documentation
  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)
  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.
  60. tasdikrahman.me || @tasdikrahman