Embed Size (px)
Citation preview
How TDD can protect you from your own experience
TDD: Cultivating a Beginner’s Mind
Shai Yallin, Head of Backend Engineering
linkedin.com/electricmonk@[email protected]
Your job is not
to write code
TDDis not
about testing
Youare not
a software engineer
01 02 03
Hi.I’m Shai Yallin.o Coding since 1994o Engineering software and culture at Wix.com since 2010 o Involved with Israeli Scala and TDD communitieso Rewrote big chunks of Wix backend code
There is a common misconception of what design is.
01
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
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.
“ “
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.
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.
“ “
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.
“ “
To code is to design. As we grow our softwarethe design emerges.
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.
Thus, focus on interfaces and defer the implementation.
Requirements will change.
Early design decisions have bigger impact than later decisions.
Your experience makes you vulnerable.
02
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.
We make the mistake of automatically following familiar patterns.
shop.lego.com www.laserpegs.com
Always end up with cohesive, loosely-coupled, SOLID systems.
You Ain’t Gonna Need It.
www.mememaker.net
Use abstractions to form a meaningful language over the code.
LibrarianBookService
We sin in indirections and bad naming. Bad naming might fixate our thinking.
Your job is to introduce abstractions, not to write code.
www.protocol-consulting.com
rodrigueaflatounamsterdam.wordpress.com
Old habits lead to pattern abuse, indirections and over-engineering.
We need to lose the design-pattern colored glasses.
Always code as if you’re on the outside looking in.
https://campfornow.wordpress.com/2014/09/03/on-the-outside-looking-in/
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.comwww.streetnpark.com
TDD to the Rescue
03
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!
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
Refactor
pixabay.com
Make the Test Pass
Write a Failing Test
The TDD Cycle
RefactorMake 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
❑ Demonstrates the 1st use case E2E
❑ Describes the problem domain IN ENGLISH
❑ Makes NO ASSUMPTIONS about implementation details
RefactorMake the Test Pass
Write a Failing Test
❑ Pass the test with the SIMPLEST code possible – no design! ❑ End up with the WALKING SKELETON
RefactorMake the Test Pass
Write a Failing Test
❑ 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
RefactorMake the Test Pass
Write a Failing Test
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.
“ “
It is our job, a craft that requires our expertise
yet -
It is often regarded as optional or left out
The Paradox with Refactoring
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-inAbstractYAGNI
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.
