Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TDD - Cultivating a Beginner's Mind


Published on

My slides from the talk I gave at Continuous Lifecycle London 2016

Published in: Software
  • Get Paid To Write Articles? YES! View 1000s of companies hiring online writers now! ●●●
    Are you sure you want to  Yes  No
    Your message goes here

TDD - Cultivating a Beginner's Mind

  1. 1. How TDD can protect you from your own experience TDD: Cultivating a Beginner’s Mind Shai Yallin, Head of Backend Engineering
  2. 2. Your job 
 is not 
 to write code TDD
 is not 
 about testing You
 are not 
 a software engineer 01 02 03
  3. 3. Hi. I’m Shai Yallin. o Coding since 1994 o Engineering software and culture at since 2010 o Involved with Israeli Scala and TDD communities o Rewrote big chunks of Wix backend code
  4. 4. There is a common misconception of what design is. 01
  5. 5. Is it this?
  6. 6. Software design is the process of implementing software solutions to one or more set of problems. 
 One of the important parts of software design is the software requirements analysis (SRA). It is a part of the software development process that lists specifications used in software engineering. “ “
  7. 7. You are NOT a Software Engineer. 
 You do not build skyscrapers. You do not build bridges. You grow gardens. You are a Software Gardener.
  8. 8. Growing Object-Oriented Software, Guided by Tests, page XVII We used the term “Growing” because it gives a sense of how we develop incrementally. “Growing” also hints at the biological quality we see in good software, the sense of coherence at every level of structure. “ “
  9. 9. When you are programming, 
 you are doing detailed design… 
 class diagrams are not the design. programming and design [aren’t] different, we just misunderstood [them]. Coding and testing are [part of] design. “ “
  10. 10. To code is to design. As we grow our software
 the design emerges.
  11. 11. We code according to product requirements. Alas, requirements may change as the software grows. Often, this gives rise to Big Balls Of Mud.
  12. 12. Thus, focus on interfaces and defer the implementation. Requirements will change. Early design decisions have bigger impact than later decisions.
  13. 13. Your experience makes you vulnerable. 02
  14. 14. We grew up on GoF, Spring, Hibernate and the likes. Patterns and technologies are cool and exciting. 
 We want to use them. We are proud of our achievements.
  15. 15. We make the mistake of automatically following familiar patterns. Always end up with cohesive, loosely-coupled, SOLID systems.
  16. 16. You Ain’t Gonna Need It.
  17. 17. Use abstractions to form a meaningful language over the code. LibrarianBookService We sin in indirections and bad naming. Bad naming might fixate our thinking.
  18. 18. Your job is to 
 introduce abstractions, not to write code.
  19. 19. Old habits lead to pattern abuse, indirections and over-engineering. We need to lose the design- pattern colored glasses.
  20. 20. Always code as if you’re on the outside looking in.
  21. 21. 1 2 Code to interfaces rather than to implementation, by writing a new collaborator (method, class, module) from the call site. The same approach can – and should – be used when approaching systems, sub-systems and modules.
  22. 22. TDD to the Rescue 03
  23. 23. Not TDD ● Writing tests after writing production code ● Writing all tests for a module before writing the module ● Writing lots of E2E tests that are tightly-coupled to the system’s inner behavior ● Writing E2Es for the server without including the client in the flows Same rules apply on tests 
 (as for code) – YAGNI! Not E2E There should be few E2Es, 
 that are oblivious to implementation Duh!
  24. 24. TDD at Wix 2013 201420122011 Major Refactoring Of BBOM via E2E acceptance tests PETRI Developed using TDD IT/E2E infrastructure for HTTP servers Beginnings Of TDD adoption Teaching TDD As part of Wix Academy
  25. 25. Refactor Make the Test Pass Write a Failing Test The TDD Cycle
  26. 26. Refactor Make the Test Pass Write a Failing Test Kicking Off the TDD Cycle Pick one, simple feature with PM Understanding that our requirements are wrong / not accurate / not enough / 
 more difficult to implement than we thought
  27. 27. ❑ Demonstrates the 1st use case E2E ❑ Describes the problem domain IN ENGLISH ❑ Makes NO ASSUMPTIONS about implementation details Refactor Make the Test Pass Write a Failing Test
  28. 28. ❑ Pass the test with the SIMPLEST code possible – no design! ❑ End up with the WALKING SKELETON Refactor Make the Test Pass Write a Failing Test
  29. 29. ❑ LOOK FOR SMELLS in the code we wrote and affected code ❑ Determine SOLUTIONS (design patterns / missing abstractions) ❑ TEST CODE IS CODE too and should have language and abstractions Refactor Make the Test Pass Write a Failing Test
  30. 30. Refactoring [does not] alter the external behavior of the code… When you refactor you are improving the design of the code after it has been written. “ “
  31. 31. It is our job, a craft that requires our expertise yet - It is often regarded as optional or left out The Paradox with Refactoring
  32. 32. TDD is your shield TDD compels you to code 
 in small increments
 (effectively holding us back from 
 making drastic unnecessary changes). Refactoring is what aims you towards the required abstractions. When you test-drive your code, you implicitly do outside-in development. Develop from the Outside-in AbstractYAGNI
  33. 33. TDD is your shield, so: We grow up on GoF, Spring and Hibernate books. Patterns and technologies are cool and exciting. 
 We want to use them. We are proud of our achievements. Cultivating a Beginner’s Mind. Should we use them? Pride clouds our judgment. Letting go of our egos, shedding off old habits.
  34. 34. Q&A Shai Yallin linkedin/