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
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