Interactions The prey, the pack, and the hunt Your goal is to meet your customers needs That goal, and nothing else, is the prey Not throwaway prototypes Not documentation Not models You will work as a team to obtain your goal 1 sweet airbrush!! Identifying your Prey Extreme Programming offers three ways to identify your goal 1.User stories 2.Acceptance tests 3.Unit tests 2 User Stories (Review) How big should a story be? 3x5 card How many user stories is the customer allowed to generate? As many as they want When can the engineer prioritize the stories? Never! The customer does the prioritization 3 Acceptance Tests and User Stories Each user story may have multiple acceptance tests A single acceptance test validates an aspect of a user story Exercising the system the way a user would Acceptance tests tell what the customer will use to judge success Main benefit of acceptance tests: You know when you can stop developing!!! 4 Example Tests User Story: Generate a Receipt As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal 5 PriceLookup PrintReceipt items prices receipt printer Example Tests User Story: Generate a Receipt As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal Unit tests for PrintReceipt component: Input: 6-pack of craft beer; Verify: $8.99 Input: milk; Verify: $2.00 6 Example Tests User Story: Generate a Receipt As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal Unit tests for PriceLookup component: Input: Beer $8.99, Milk $2.00, Beer $ 8.99 Verify: Receipt lists items and total: $ Example Tests User Story: Generate a Receipt As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal Acceptance test (combines several unit tests): Test: Scan one 6-pack, one mile, one 6-pack Verify: Receipt lists items and total: $ Creating Acceptance Tests Ideally, customer writes acceptance tests Acceptance tests are blackbox tests The test writer doesnt get to read the testbed code Tests should be unambiguous 9 10 FIT FrameworkFramework for Integrated Test Running Acceptance Tests Run acceptance tests once a week, preferably more often Often useful to have an integration machine where you run acceptance tests Representative of what customer would have 11 Unit Tests (Review) Who write the unit tests? Programmer! When do unit tests get written? Before writing the application code 12 Benefits of Unit Tests Clarifies the task at hand Frees you from writing perfect code (temporarily) Make reliable refactoring possible 13 Creating Unit Tests Unit tests start out as blackbox tests, become whitebox tests First created for non-existent code At any time, you can read your (new) application code and revise the test code Exhaustive testing is usually infeasible Use representative testing instead Typical inputs Boundary cases 14 Creating Unit Tests Writing the first test is the hardest Your test suite is more valuable than your code If you want a good suite of tests next year, you must being collecting them today 15 When to Program You only write code when the test suite is broken or if you are refactoring Your twin goals: Pass the unit tests for todays user stories Refactor to keep things under control 16 The Hunt is not Yours Alone Its not your code, its the teams code Egoless programming doesnt work; expand your ego to include everyones code Anybody can edit any code that has been checked in 17 Benefits of Pair Programming Similar to a real-time code review Copilot can help catch implicit assumptions Pair programming takes 15% longer but leads to 15% fewer bugs (a win for many projects) Ideas and techniques spread throughout group 18 Pair Programming: The Driver Controls the keyboard and mouse Is actively talking to the copilot Explains intent of code and where he/she is going 19 Pair Programming: The Copilot Not a passenger!! Pays attention, watches for mistakes, offers ideas Talk about and agree upon best course of action If you cant agree, then take turns yielding to each others preferences At any moment, copilot can request to switch places and drive Driver can say hold on a second, but should switch as soon as possible You are working as a pair, a team 20 Principles of Pair Programming If someone asks to pair with you, (and you can), you must say yes (No playing favorites) Code formatting: pick a standard as a team, enforce, move on Font size: choose a font large enough for copilot to see Take turns pairing with many different people If you write code alone, then it must be rewritten 21 Interacting with Team Periodically communicate progress E.g., end-of-dayTrack progress with wiki or other tools Use models judiciously Draw diagrams to help you reason Draw diagrams to communicate Only draw diagrams if it helps your team get the prey 22 Models in Agile Processes Must provide value Must fulfill a purpose Must be understandable Must be as simple as possible Must be sufficiently: Accurate Concise Detailed 23 NOT TRUE about Models in Agile Models = documentation Modeling implies a heavyweight process Modeling freezes requirements Models never change Models are complete Models must be created with a tool All developers must know how to model properly Modeling is a waste of time The data model is the only one that matters 24 Tips for Agile Modeling Dont let the models distract from the hunt Model iteratively and incrementally Model with other people Stakeholders Collectively (as a team) Display models publicly Create simple content Use the simplest tools 25 More Tips for Agile Modeling Dont spend time getting things perfect Follow agreed upon standards Reuse existing resources Discard temporary models 26 The prey, the pack, and the hunt Your goal, and nothing else, is to meet your customers needs Each of these is a means to an end, not an end in itself Acceptance tests Unit tests Pair programming Modeling You will work as a team to obtain your goal 27 Next Steps Final Vision Statement due Friday!! (11/21) No late material will be accepted Midterm due 11/25 No late material will be accepted Homework #6 (Implementation Plan) due 12/03 28