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 flow
red giant

blue-white
super giant
single change affects 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 diff
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