250 likes | 440 Views
Note 6. Extreme Programing and Test-Driven Development. Yan Shi Lecture Notes for SE 3730 / CS 5730. Outline. What is extreme programming? 12 key practices of XP. Test-driven development. Extreme Programming (XP). One of several popular Agile Processes . http://www.extremeprogramming.org.
E N D
Note 6. Extreme Programing and Test-Driven Development Yan Shi Lecture Notes for SE 3730 / CS 5730
Outline • What is extreme programming? • 12 key practices of XP. • Test-driven development
Extreme Programming (XP) • One of several popular Agile Processes. http://www.extremeprogramming.org
Extreme Programming (XP) • Zoom into each iteration: http://www.extremeprogramming.org
The Whole team • Put the whole team in one room. • The team must include a customer advocate who can provide requirements and set priorities. • The customer advocate must possess end user domain knowledge. • Other roles that must be filled are: • Testers – who help the customer construct acceptance tests. • Analysts – who help the customer define/refine specifications. XP uses short descriptions called stories. Generally no more than fits on a note card. • Manager – who provides resources, handles external communications, and coordinates activities. • Designer/Programmers – design, implement, test, and optimize the code.
Collective Ownership • All team members are allowed access to all code! • No need to wait for the “owner of the code”! • If a problem is found, it can be fixed by the finder immediately. • If an enhancement is necessary, get it done. • Benefit: speed up the development! • People may not work on code they are familiar with. Is it a problem? • spread of knowledge because of team rotation • pair programming • automated unit test to run against
Metaphor • Metaphor: a simple shared story of how the program works (developed by the team). • unify an architecture • share common sets of names and terms • Car or vehicle? • Client or customer? • Benefit: make sure all communication is accurate.
Planning Game • Create a little emotional distance from planning by treating it as a game. • Release planning • The customer defines stories and programmers provide rough cost estimates. • The customer decides the priorities. • Break stories into small groups releases. • Iteration planning • Average iteration shoots for ~2 weeks • The customer does fine tuning of what will be delivered. • The team break stories into tasks and estimate costs. • Together they decide what will be in the next iteration/release. • The release plan is dynamic and updated at each iteration plan.
Small Release • Each release is very short and you only provide the code for a very small set of functionalities (a few stories). • Releases are delivered to end users for evaluation and feedback. • visible progress: Customer would rather see a product than a status report! • instant feedback.
Continuous Integration • The system is fully integrated at all time. • Systems are built, integrated and tested at least once a day. (nightly build) • Share each refactor/addition with all team members immediately. • Small increments fast integration: system is never far from last successful integration.
Customer Tests • Customers define automated acceptance tests for each feature. • XP team builds the tests. • Objective: review and validate requirements. • Automation of tests is important: • regression test: unit, integration, acceptance
Sustainable Pace • Originally “40-hour week”. • Work when you are fresh; stop when you are tired! • Minimize overtime to keep people working efficiently and keep spirits up. • Working longer hours may become counter-productive: higher error rate, less LOC/hour, worse health, more stress, … • Jobs that require complex mental functions can sustain 60 hour weeks for very short duration!
Simple Design • Design on the go! • Start simple and keep it simple. • At release planning, have a sketch of the overall picture. • At iteration planning, have a quick design session. • Refine your design: look for simpler alternatives. • Refactor previous design to adjust to new features or to optimize. • XP does no spend less time on analysis and design; it only spreads it out more evenly!
Refactoring • Design and code continuous improvement! • e.g. a = y*y+2*y*x+x*x; • After finishing each feature, refactor to • decrease complexity; • achieve high coupling and low cohesion; • Code Smells – ways to identify things to improve • Classes/Methods are too long • Switch statement (instead of inheritance) • “Struct” class ( lots of getter and setters but few functions) • Duplicate code • Over-dependence on primitive types • many more… • a=x+y; a=a*a;
Pair Programming • “My mind to your mind. My thoughts to your thoughts...” • Two roles: • driver: write the code • copilot/navigator: watch, correct, suggest • Pair with multiple partners • spread the ideas and techniques within the group • Benefit of Pair Programming: • Real-time code reviews • typos, cognitive dropouts, and invalid assumptions • Avoid distractions • Managing of two • Knowledge and information migration
Coding Standards • People on a team often have different preferences and might need to agree on something. • Adherence to a strong coding standard makes the code easy for anyone on the team to follow. • naming convention: BumpyCase or underscore? • where to put the braces? • indentation • tabs • …
Test Driven Development • In each release, before coding, develop a unit test for each story! • Make the test work by adding code. • The tests become part of the product and are executed every time the code is released/refactored. • Key: don’t do more than needed! • Why TDD? • The developer is better focusing on what MUST be implemented to pass the unit test. • The code is unit tested when completed. • Provide documentation for different team members.
Wake’s Traffic Light Metaphor Yellow The test doesn’t compile! classes and methods need to be implemented. Red The test compiles, but the code fails. work on the code. Green The test passes! check in the code and continue to the next story.
Normal Cycle • Start. (Green light!) • Write a test. • Try to run the test. • It fails to compile, because the code is not written yet. (Yellow light!) • Write a stub for the new routine. • Recompile the test and the stub • It now compiles • Try to run the test. It fails, because the stub doesn't do anything yet. (Red light!) • Write the body of the stubbed routine. • Recompile the test • Try to run the test. It passes. (Green light again!) Or it still needs work (Red light!) and the production code needs more work. • Eventually it will work and go to (Green light) • Start the cycle again for the next routine.
Abnormal Conditions • From Greento Green: • From Greento Red: • From Yellowto Yellow: • From Yellowto Green: • From Redto Yellow: • From Redto Red:
Abnormal Conditions • From Greento Green:The test passed right away. • Either the test is bad, or you've already implemented the feature being tested. • You might consider modifying the implementation just to see the test fail. • From Greento Red:The test failed right away. • This is OK if it's a new test for an existing routine. rework the routine! • From Yellowto Yellow:syntax error creating the stub. • From Yellowto Green:The test didn't compile without the stub, but adding the stub let the test pass. • Suspicious: if a do-nothing stub makes the test work, is the test valid? • From Redto Yellow:syntax error implementing the routine. This happens a lot! • From Redto Red:New code didn't work. • This happens to everyone - just fix the code. But - if it happens a lot, it's telling you to move to smaller tests (so you'll add smaller bits of new code as well).
Summary • 12 key practices of XP + • TDD • traffic light metaphor