Interactions

The prey, the pack, and the hunt Your goal is to meet your customer’s 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? 3”x5” 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 doesn’t get to read the testbed code Tests should be unambiguous 9

10 FIT Framework Framework 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 today’s user stories Refactor to keep things under control 16

“The Hunt is not Yours Alone” It’s not your code, it’s the team’s code “Egoless programming doesn’t work; expand your ego to include everyone’s 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 can’t agree, then take turns yielding to each other’s 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-day Track 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 Don’t 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 Don’t 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 customer’s 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