Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

TDD: An experience report

Tasdik Rahman
December 03, 2020

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. • Software Engineer @ Gojek (Engg Platform) • Formerly, #4

    in the cloud infra team @ Razorpay • Past contributor to oVirt • Backpacker • Chelsea FC!! tasdikrahman.me || @tasdikrahman
  2. Side projects Come across foo problem/ itch for solving some

    foo problem Have an MVP ready Share with friends/twitter/reddit
  3. 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.
  4. 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
  5. 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
  6. 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
  7. Has been some time since it has had any contributions

    Link: https://github.com/tasdikrahman/tnote
  8. 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
  9. 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
  10. 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
  11. TDD? Write a spec, get it to fail Make it

    pass/ implement the spec Refactor/ remove duplication
  12. 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
  13. 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
  14. 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
  15. No

  16. 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
  17. 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
  18. No

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

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

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

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

    Robust and extensive E2E testing (preferably automated) Type system Documentation
  23. 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)
  24. 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.