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

1. How TDD can protect you from your own experience
TDD: Cultivating a Beginner’s Mind
Shai Yallin, Head of Backend Engineering
linkedin.com/electricmonk@shaiyallinshaiy@wix.com

2. Your job
is not
to write code
TDD
is not
about testing
You
are not
a software engineer
01 02 03

3. Hi.
I’m Shai Yallin.
o Coding since 1994
o Engineering software and culture at Wix.com since 2010
o Involved with Israeli Scala and TDD communities
o Rewrote big chunks of Wix backend code

4. There is a common misconception
of what design is.
01

5. Is it this?
http://www.u.arizona.edu/~przybyls/labels/software.html
http://www.tracemodeler.com/gallery/java%20io%20-%20reading%20an%20int%20from%20a%20file.html

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. http://www.chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer/
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. 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. http://c2.com/cgi/wiki?WhatIsSoftwareDesign
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. To code is to design.
As we grow our software
the design emerges.

11. http://www.laputan.org/mud/
http://effectivesoftwaredesign.com/2013/06/17/the-myth-of-emergent-design-and-the-big-ball-of-mud/
http://www.bonsaitreegardener.net/care/growing-from-seed
www.stylepinner.com
We code according to product requirements.
Alas, requirements may change as the software grows.
Often, this gives rise to Big Balls Of Mud.

12. Thus, focus on
interfaces and defer
the implementation.
Requirements will
change.
Early design
decisions have
bigger impact than
later decisions.

13. Your experience makes you
vulnerable.
02

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. We make the mistake of automatically following
familiar patterns.
shop.lego.com
www.laserpegs.com
Always end up with cohesive,
loosely-coupled, SOLID systems.

16. You Ain’t Gonna
Need It.
www.mememaker.net

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. Your job is to
introduce abstractions,
not to write code.
www.protocol-consulting.com

19. rodrigueaflatounamsterdam.wordpress.com
Old habits lead to pattern abuse,
indirections and over-engineering.
We need to lose the design-
pattern colored glasses.

20. Always code as if
you’re on the outside
looking in.
https://campfornow.wordpress.com/2014/09/03/on-the-outside-looking-in/

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.
apivoice.com
www.streetnpark.com

22. TDD to the
Rescue
03

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. 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. Refactor
pixabay.com
Make the
Test Pass
Write a
Failing Test
The TDD Cycle

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. ❑ 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. ❑ 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. ❑ 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. http://martinfowler.com/books/refactoring.html
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. 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. 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. 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. Q&A
http://www.shaiyallin.com/
Shai Yallin
linkedin/electricmonk@shaiyallinshaiy@wix.com