TDD: An experience report
tasdikrahman.me || @tasdikrahman
Slide 2
Slide 2 text
tasdikrahman.me || @tasdikrahman
Slide 3
Slide 3 text
● Software Engineer @ Gojek (Engg Platform)
● Formerly, #4 in the cloud infra team @ Razorpay
● Past contributor to oVirt
● Backpacker
● Chelsea FC!!
tasdikrahman.me || @tasdikrahman
Slide 4
Slide 4 text
Side projects
Image credits: wikipedia
Slide 5
Slide 5 text
Side projects
Come across foo
problem/
itch for solving some
foo problem
Slide 6
Slide 6 text
Side projects
Come across foo
problem/
itch for solving some
foo problem
Have an MVP ready
Slide 7
Slide 7 text
Side projects
Come across foo
problem/
itch for solving some
foo problem
Have an MVP ready
Share with
friends/twitter/reddit
Slide 8
Slide 8 text
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.
Slide 9
Slide 9 text
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
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
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
Stale PRs
Link: https://github.com/tasdikrahman/tnote
Slide 23
Slide 23 text
So what happened here
Slide 24
Slide 24 text
So what happened here
Context lost over
time/forgot why x
decision was
taken/not taken
Slide 25
Slide 25 text
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
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
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
Slide 28
Slide 28 text
Time for another example
Slide 29
Slide 29 text
Time for another example
Link: https://github.com/tasdikrahman/bhola/
Slide 30
Slide 30 text
What was done differently?
Slide 31
Slide 31 text
TDD for a change
1st PR for the project:
https://github.com/tasdikrahman/bhola/pull/5
Slide 32
Slide 32 text
TDD?
Slide 33
Slide 33 text
TDD?
Red
Green
Refactor
Slide 34
Slide 34 text
TDD?
Write a spec,
get it to fail
Make it pass/
implement
the spec
Refactor/
remove
duplication
Slide 35
Slide 35 text
Baby steps
Slide 36
Slide 36 text
Breaking problem into
multiple steps
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
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
Slide 39
Slide 39 text
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
Slide 40
Slide 40 text
Is 100% coverage gonna
provide bug free software?
Slide 41
Slide 41 text
No
Slide 42
Slide 42 text
Quick example from the
same project
Slide 43
Slide 43 text
Relevant PR: https://github.com/tasdikrahman/bhola/pull/65
Wrong value being stubbed
Slide 44
Slide 44 text
Bugs even
though it
had 99.4%
coverage
Slide 45
Slide 45 text
Undesirable Side effects of
high code coverage
Slide 46
Slide 46 text
Undesirable Side effects of
high code coverage
Needs maintenance
similar to production
codebase
Slide 47
Slide 47 text
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
Slide 48
Slide 48 text
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
Slide 49
Slide 49 text
Is TDD the silver bullet?
Slide 50
Slide 50 text
No
Slide 51
Slide 51 text
Where would I think of not
practicing TDD?
Slide 52
Slide 52 text
Where would I think of not
practicing TDD?
While scripting
something quick
Slide 53
Slide 53 text
Where would I think of not
practicing TDD?
While scripting
something quick
When the interface is
loose/changing too fast
Slide 54
Slide 54 text
Some other ways to have
more confidence in your
codebase
Slide 55
Slide 55 text
Some other ways to have more
confidence in your codebase
Robust and extensive
E2E testing (preferably
automated)
Slide 56
Slide 56 text
Some other ways to have more
confidence in your codebase
Robust and extensive
E2E testing (preferably
automated)
Type system
Slide 57
Slide 57 text
Some other ways to have more
confidence in your codebase
Robust and extensive
E2E testing (preferably
automated)
Type system Documentation
Slide 58
Slide 58 text
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)
Slide 59
Slide 59 text
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.