Download - Test-Driven Design - ¿Porqué?
![Page 1: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/1.jpg)
Test-driven Design/Development
![Page 2: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/2.jpg)
TDD• First agile practice to become mainstream
• Chrysler Comprehensive Compensation system
• They needed something different
• BUFP wasn’t working
• How to deal with change instead of fighting it?
![Page 3: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/3.jpg)
Lean - Dealing with Change• Planning
• Incremental
• frequent
• Small
• features
• releases
![Page 4: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/4.jpg)
Agile - Dealing with Change
• Plan driven vs Planning Driven
• Revise the plan weekly
• reflect reality
• make appropriate decisions
![Page 5: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/5.jpg)
Lean Manufacturing
• View the problem as a Software Delivery System
• Programmers, testers, designers, managers, BBAA.
• Input: Feature request
• Output: Let’s decide...
![Page 6: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/6.jpg)
Lean: “The Goal”- Eliyahu Goldratt
• Alex run a manufacturing plant soon to be closed
• He knows a consultant (Jonah)!!
• He learns a systems approach to manufacturing and its evaluation
• This new system is counterintuitive: Not seeking 100% machine utilization
![Page 7: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/7.jpg)
Lean Basics: The Goal
• Increase the throughput
• Decrease operating expenses
• Decrease inventory
![Page 8: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/8.jpg)
Lean: Throughput
• How much potential revenue the system can create
• Emphasis in deliver real software to real customers. It is only paid if it is used.
• Running Tested Features per time unit
• RFT/month
![Page 9: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/9.jpg)
Lean: Operating expenses
• Computers
• Electricity
• Rent
• Insurance
• Wages ...
![Page 10: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/10.jpg)
Lean:Inventory
• Grocery Store
• What is in the shelve
• I bet I can sell it on time
• It is not providing value (value = money)
![Page 11: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/11.jpg)
Inventory in Software?
• Unused Features: Building a feature nobody is using [no payments]
• Unreleased features in source control
• Unnecessary complexity:
• A developer adds complexity in anticipation of a future feature
![Page 12: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/12.jpg)
Inventory & Machine Utilization
• Machine spits out parts at 100% utilization
• Only 25% ended up ordered
• 8 hour shift: 200 sold and 600 stacking up on the floor
• Walk around parts, new warehouse!
• Operating expenses increased! Don’t use it at 100%
![Page 13: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/13.jpg)
Inventory: Unnecessary Complexity
• Developer adds complexity in anticipation
• Developer will have to walk around these parts from now on [we have spoiled customers!!]
• Developers are slowed down
• More complexity
• Probably adding duplication
![Page 14: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/14.jpg)
Inventory: Unnecessary Complexity
• The more unnecessary complexity
• The more difficult to change
• The harder to maintain
• Marginal costs of features goes up
• The harder to maintain a system
• The more expensive the feature
![Page 15: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/15.jpg)
TDD’s goal is to reduce Inventory
Keeping the cost of adding a feature as low as we can by keeping the design simple
![Page 16: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/16.jpg)
Lean Basics: The Goal
• Increase the throughput (RTF/month)
• Decrease operating expenses, - precedence
3.Decrease inventory
• Reduce unnecessary complexity
• Reduce unused features
• Reduce unreleased features
![Page 17: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/17.jpg)
YAGNI - Decrease Unneeded Complexity
• Design only what I need to solve the problem I have now :-(
• I design what I need now in such a way that is ready for any change :-)
• Example: Personal defense failure
![Page 18: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/18.jpg)
YAGNI - Decrease Unneeded Complexity• Design in a way that prevents attacks from
any direction
• Follow few principles to keep the design simple so the cost of implementing any new feature is reasonably low
• Example: Personal defense Principles
![Page 19: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/19.jpg)
TDD Principles• Design is simple if it
• passes the test
• minimizes duplication
• maximizes clarity
• is small
• 1. is assumed and 4. is a by-product
![Page 20: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/20.jpg)
TDD Principle: Reduce Duplication
“I’m doing the same thing in five places, I have to change all five of them [Put rationalized justification] so I copied and pasted in four places, I forgot the fifth one” bug ⇒
![Page 21: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/21.jpg)
TDD Principle: Fix Bad Names
• By naming accurately
• It is easier to understand how the code works
• we may detect smells (name too weird?)
![Page 22: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/22.jpg)
TDD Principle: Maximize Clarity
• Fix bad names
• name variables after what they represent
• name methods after what they do
• name classes what they are
• name interfaces after what the role they play
![Page 23: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/23.jpg)
TDD Principle: Fix Bad Names
• Smell: too long with connectors like: “and”, “then”, “but”. That block of code
• is doing too much work
• too many responsibilities
• it duplicates responsibilities with another part of the system
![Page 24: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/24.jpg)
TDD Principles• Design is simple if it
• minimizes duplication
• maximizes clarity
• Claim: IF WE FOLLOW THESE PRINCIPLES WE REDUCE INVENTORY CREATED BY UNNECESSARY COMPLEXITY
![Page 25: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/25.jpg)
TDD: Recfatoring
• Improving the design of existing code [book]
• Systematic approach to improve the design without throwing a piece a way while rewritten it.
![Page 26: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/26.jpg)
Refactoring: Systematic Approach
• Work in very small steps
• steps are reversible
• I can stop if I want to
• Keep the code working at every step
• I have tests (behavioral spec) that tells me if a structural change breaks behavior
![Page 27: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/27.jpg)
Traditional Design
• We design something that meets a large number of requirements at once [cascade] Done by architects, handed off to developers
• Caveat with high level design ideas:
• high levels ideas right most of the time
• low level detail wrong most of the time
![Page 28: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/28.jpg)
Evolutionary Design
• The act of writing the code give us information wether the design works or not, without that information, we can’t design effectively.
• Write code in a way that allows us to start with the low level detail and use some basic principles to make sure the high level ideal designs ideas work well
![Page 29: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/29.jpg)
Evolutionary Design by TDD
• Test drives the design.
• A test articulates a goal so I know when to stop
![Page 30: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/30.jpg)
Evolutionary Design: TDD cycle
• Write a failing test
• Articulates a goal: “I need a little piece of software to does this”
• Make the test pass:
• Don’t write any production code if there isn’t a failing test that requires it [no inventory]. Failing test evidence of need
![Page 31: Test-Driven Design - ¿Porqué?](https://reader034.vdocuments.us/reader034/viewer/2022052508/5599e3791a28ab2f668b45fe/html5/thumbnails/31.jpg)
Evolutionary Design: TDD cycle
• A new intellectual challenge
• write it simple
• articulate the goal with less code
• pass the test with less code
• remove duplication, make it clearer