TEST DRIVEN
DESIGNLEMi ORHAN ERGiN
software craftsman @ acm
LEMi ORHAN ERGiN
agile software craftsman @ acm
/lemiorhan
lemiorhanergin.com
@lemiorhan
managing partner at acm
developing since 2001
worked at Sony and eBay/GittiGidiyor
consultant, architect, trainer, developer
founder of Software Craftsmanship Turkey
ex product owner of Agile Turkey Summit
meetup.scturkey.org
summit.agileturkey.org
Jack W. Reeves
The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
What is So!ware Design?
Source code is the real
so!ware design
Designing so!ware is an exercise in managing complexity
Jack W. Reeves
What is Software Design? The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
The so!ware design is
not complete until it has
been coded and tested
Testing is part of the process of refining the design
Jack W. Reeves
What is Software Design? The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
Programming
Source Code
SOFTWARE DESIGN
Test and
Verification
The very first value of
so!ware isโ€ฆ
Robert C. Martin
Author of Clean Code and Clean Coder
Owner of cleancoders.com training site
The very first value of
so!ware is to tolerate and
facilitate on-going changes
Robert C. Martin
Author of Clean Code and Clean Coder
Owner of cleancoders.com training site
Each city has to be renewed in order to
meet the needs of its populace.
So!ware-intensive systems are like that.
Grady Booch
Developed UML
Wrote foreword to
โ€œDesign Patternsโ€ and
โ€œTechnical Debtโ€ books
Istanbul, TurkeyCredit: European Space Imaging
Programming
Source Code
SOFTWARE DESIGN
Refactoring
Test and
Verification
Everything is part of the
design process
Jack W. Reeves
What is Software Design? The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
butโ€ฆ
we develop
without
driving
the design
nebulaconcepts and terminology trigger ideas about the design
what we really do in generalโ€ฆ
proto-star
initial classes containing the logic
simple structure, basic domain model and behaviors
brown dwarfbasic dependencies, works as we expect
utility classes start to occur
main sequence star
needless complexity starts, a lot of inter-dependencies
manual testing starts to take longer time than usual
hard to add new features
too much debugging
too many workarounds
too complex to know every ๏ฌ‚ow
red giant
blue-white
super giant
single change a๏ฌ€ects many areas,
no reuse - duplication hell,
fragile system - unstable prod
scary refactoring,
silos occur
red super giant
huge classes, tons of workarounds,
no new features, maintenance mode rules,
basic implementations take weeks,
no one knows how overall system works,
rollbacks a!er deployments,
architect saves the company
supernova
employee turnovers,
frustrated management,
blame & fight
black hole
deadly loop of total rewrite or exit from the market
Programming
Source Code
SOFTWARE DESIGN
Refactoring
Test and
Verification
Programming
Source Code
SOFTWARE DESIGN
Refactoring
good?
Test and
Verification
COUPLING
When readfile() is changed, do you change writeFile() too?
It shows how many places we need to change
Two elements are loosely
coupled if they are not
shown in the same di๏ฌ€
Kent Beck
The creator of extreme programming
One of the signatories of the Agile Manifesto
Pioneered software design patterns and TDD
COHESION
Do you search a lot where to change?
It shows how easy to find the places we need to change
How many files at any
one time is still open for
edit shows the level of
cohesion
Nat Pryce
Co-Author of Growing Object-Oriented Software Guided by Tests
Early adopter of XP
Programming
Source Code
SOFTWARE DESIGN
Refactoring
Low Coupling
Test and
Verification
High Cohesion
Programming
Source Code
SOFTWARE DESIGN
Refactoring
is hard and needs discipline!
Test and
Verification
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Programming
Source Code
Test and
Verification
SOFTWARE DESIGN
Refactoring
Test Driven
High CohesionLow Coupling
Unit testing frameworks
Mocking frameworks
Automated testing types
Design principles
Refactoring techniques
Clean code principles
LEARN
Continuous Integration
Source code versioning
Notification mechanism
Code coverage monitoring
Practice TDD via katas
Develop via TDD
Acceptance testing via TDD
Verify by behaviours via BDD
ESTABLISH
PERFORM
Unit testing frameworks
Mocking frameworks
Automated testing types
Design principles
Refactoring techniques
Clean code principles
LEARN
Continuous Integration
Source code versioning
Notification mechanism
Code coverage monitoring
Practice TDD via katas
Develop via TDD
Acceptance testing via TDD
Verify by behaviours via BDD
ESTABLISH
PERFORM
Unit testing frameworks
Mocking frameworks
Automated testing types
Design principles
Refactoring techniques
Clean code principles
LEARN
Continuous Integration
Source code versioning
Notification mechanism
Code coverage monitoring
Practice TDD via katas
Develop via TDD
Acceptance testing via TDD
Verify by behaviours via BDD
ESTABLISH
PERFORM
Unit testing frameworks
Mocking frameworks
Automated testing types
Design principles
Refactoring techniques
Clean code principles
LEARN
Continuous Integration
Source code versioning
Notification mechanism
Code coverage monitoring
Practice TDD via katas
Develop via TDD
Acceptance testing via TDD
Verify by behaviours via BDD
ESTABLISH
PERFORM
small set of entities
few lines in methods
follows OOP design guidelines
simple design, names are the intensions
marbles
If you really want to see something interesting:)
ursa minor
and polaris
LEMi ORHAN ERGiN
agile software craftsman @ acm
/lemiorhan
lemiorhanergin.com
@lemiorhan

Test Driven Design