Test Driven Design - GDG DevFest Istanbul 2016

Software

lemi-orhan-ergin
  • TEST DRIVEN DESIGN LEMi ORHAN ERGiN software craftsman @ acm
  • DESIGN LEMi ORHAN ERGiNagile 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++ Journal Vol. 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++ Journal Vol. 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++ Journal Vol. 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++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
  • but… we develop without driving the design
  • nebula concepts 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 dwarf basic 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 RefactoringLow Coupling Test and Verification High Cohesion
  • Programming Source Code SOFTWARE DESIGN Refactoring is hard and needs discipline! Test and Verification 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
  • 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
  • LEMi ORHAN ERGiN agile software craftsman @ acm /lemiorhan lemiorhanergin.com @lemiorhan
Please download to view
46
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Description
Text
  • TEST DRIVEN DESIGN LEMi ORHAN ERGiN software craftsman @ acm
  • DESIGN LEMi ORHAN ERGiNagile 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++ Journal Vol. 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++ Journal Vol. 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++ Journal Vol. 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++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
  • but… we develop without driving the design
  • nebula concepts 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 dwarf basic 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 RefactoringLow Coupling Test and Verification High Cohesion
  • Programming Source Code SOFTWARE DESIGN Refactoring is hard and needs discipline! Test and Verification 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
  • 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
  • LEMi ORHAN ERGiN agile software craftsman @ acm /lemiorhan lemiorhanergin.com @lemiorhan
Comments
Top