Note 6. Extreme Programing and Test-Driven Development

1. Note 6. Extreme Programing and Test-Driven Development Yan Shi Lecture Notes for SE 3730 / CS 5730

2. Outline • What is extreme programming? • 12 key practices of XP. • Test-driven development

3. Extreme Programming (XP) • One of several popular Agile Processes. http://www.extremeprogramming.org

4. Extreme Programming (XP) • Zoom into each iteration: http://www.extremeprogramming.org

5. 12 Key Practices of XP

6. 12 Key practices of XP

7. 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.

8. 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

9. 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.

10. 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.

11. 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.

12. 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.

13. 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

14. 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!

15. 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!

16. 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;

17. 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

18. 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 • …

19. Test driven development

20. 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.

21. 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.

22. 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.

23. Abnormal Conditions • From Greento Green: • From Greento Red: • From Yellowto Yellow: • From Yellowto Green: • From Redto Yellow: • From Redto Red:

24. 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).

25. Summary • 12 key practices of XP + • TDD • traffic light metaphor