Computer Science and Software Engineering University of Wisconsin - Platteville 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.

Extreme Programming (XP)  Zoom into each iteration:

12 Key Practices of XP Team Whole teamCollective ownershipMetaphor Process Planning gameSmall releaseContinuous integrationCustomer testsSustainable pace Programming Simple designRefactoringPair programmingCoding standards

12 KEY PRACTICES OF XP

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 TDD!

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 cohesion and low coupling;  Code Smells – ways to identify things to improve Code Smells —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

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 Red Green The test doesn’t compile! The test compiles, but the code fails. The test passes!  classes and methods need to be implemented.  work on the code.  check in the code and continue to the next story.

Normal Cycle 1.Start. (Green light!) 2.Write a test. 3.Try to run the test.  It fails to compile, because the code is not written yet. (Yellow light!) 4.Write a stub for the new routine. 5.Recompile the test and the stub  It now compiles 6.Try to run the test. It fails, because the stub doesn't do anything yet. (Red light!) 7.Write the body of the stubbed routine. 8.Recompile the test 9.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) 10.Start the cycle again for the next routine.

Abnormal Conditions  From Green to Green:  From Green to Red:  From Yellow to Yellow:  From Yellow to Green:  From Red to Yellow:  From Red to Red:

Abnormal Conditions  From Green to 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 Green to Red: The test failed right away. —This is OK if it's a new test for an existing routine.  rework the routine!  From Yellow to Yellow: syntax error creating the stub.  From Yellow to 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 Red to Yellow: syntax error implementing the routine. This happens a lot!  From Red to 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