Successfully reported this slideshow.
Your SlideShare is downloading. ×

TDD - Designing with Expectations, not Implementations

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
TDD
TDD
Loading in …3
×

Check these out next

1 of 24 Ad

TDD - Designing with Expectations, not Implementations

Download to read offline

TDD approach made simple based on the experience and journey gone through learning and implementing it in a large scale android app, i.e. Shaadi.com.

TDD approach made simple based on the experience and journey gone through learning and implementing it in a large scale android app, i.e. Shaadi.com.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to TDD - Designing with Expectations, not Implementations (20)

Advertisement

Recently uploaded (20)

TDD - Designing with Expectations, not Implementations

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

×