1.
Designing with Expectations, not
Implementations
Harshith Shetty

2.
Test
● When to write tests?
● Does your test run fast?

3.
Why TDD?

4.
● Ask
● Describe
● Fulfill
● Move on
Approach

5.
Ask (what it’ll do)
● Expectations from the feature
● Clarity
● Documentation

6.
Describe (how it’ll do)
● Interfaces of the feature
● Relationship between objects
● Flow of the feature
● Knowing when it’s done

7.
Some Mocks:

8.
Examples:

9.
Fulfill (make it do)
● Implementation of feature
● Decoupled code
● Separation of business Logic from platform
● Faster feedback

10.
Move on
*Test
*You

11.
Move on
● Regression tests

12.
Real life scenario
3 buttons x
7 states x
3 user types x
2 experiments
= 126 cases

13.
*Refactoring
*New Features
*You
*Changing
Requirements
*Legacy code

14.
3 Laws of TDD
● You must write a failing test before you write any
production code.
- Robert C. Martin (Uncle Bob)
● You must not write more of a test than is sufficient to
fail, or fail to compile.
● You must not write more production code than is
sufficient to make the currently failing test pass.

15.
Benefits
● Documented code
● Better code reviews
● Rewarding
● Refactor with Confidence
● Faster development cycles
● Less Debugging

16.
Notes
● Always test the interfaces, Requirements are stable,
implementations are not.
● Follow a clean architecture.
● Practice. Practice. Practice. Make it a habit.
● Split the code, if tests become more.
● If not for product, do it for you.
● If not for you, do it for the next developer.

17.
Examples:

18.
Examples:

19.
Examples:

20.
● @har5hit
● @ShaadiTech
Contact

21.
● “Ruby Midwest 2011 - Keynote: Architecture the Lost Years
by Robert Martin”
https://www.youtube.com/watch?v=WpkDN78P884
● “The Three Laws of TDD (Featuring Kotlin)”
https://www.youtube.com/watch?v=qkblc5WRn-U
● Growing Object-Oriented Software: Guided By Tests
by Steve Freeman
References