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