TDD - Designing with Expectations, not Implementations
- 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
- 12. Move on ● Regression tests
- 13. Real life scenario 3 buttons x 7 states x 3 user types x 2 experiments = 126 cases
- 17. 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.
- 18. Benefits ● Documented code ● Better code reviews ● Rewarding ● Refactor with Confidence ● Faster development cycles ● Less Debugging
- 19. 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.
- 20. Examples:
- 21. Examples:
- 22. Examples:
- 24. ● “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