Designing with Expectations, not
Implementations
Harshith Shetty
Test
● When to write tests?
● Does your test run fast?
Why TDD?
● Ask
● Describe
● Fulfill
● Move on
Approach
Ask (what it’ll do)
● Expectations from the feature
● Clarity
● Documentation
Describe (how it’ll do)
● Interfaces of the feature
● Relationship between objects
● Flow of the feature
● Knowing when it’s done
Some Mocks:
Examples:
Fulfill (make it do)
● Implementation of feature
● Decoupled code
● Separation of business Logic from platform
● Faster feedback
Move on
*Test
*You
Move on
● Regression tests
Real life scenario
3 buttons x
7 states x
3 user types x
2 experiments
= 126 cases
*Refactoring
*New Features
*You
*Changing
Requirements
*Legacy code
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.
Benefits
● Documented code
● Better code reviews
● Rewarding
● Refactor with Confidence
● Faster development cycles
● Less Debugging
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.
Examples:
Examples:
Examples:
● @har5hit
● @ShaadiTech
Contact
● “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

TDD - Designing with Expectations, not Implementations