Today’s lecture
•
•
•
•
•
Acceptance tests
Review of unit tests
Pair programming
Models and communication
Continuous improvement
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.
http://www.flickr.com/photos/orinrobertjohn/3598881393/sizes/s/
Identifying your prey
• Extreme Programming offers three ways to
identify your goal.
– User stories
– Acceptance tests
– Unit tests
Pop quiz on user stories
• How big should a story be?
• 3x5” card
• How many user stories is the customer
allowed to generate?
• As many as desired
• When can the engineer prioritize the stories?
• Never. The customer does the prioritization
Acceptance tests and user stories
• Each user story may have multiple acceptance
tests.
• A single acceptance test validates an aspect of
a user story by exercising the system the way
that 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!
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.”
items
items
PriceLookup
PrintReceipt
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 PriceLookup component
Input: 6-pack of beer; Verify: $6.47
Input: milk; Verify: $2.00
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: Beer $6.47, Milk $2.00, Beer $6.47
Verify: Receipt lists items and total is $14.94
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 1 6-pack, 1 milk, 1 6-pack
Verify: Receipt lists items and total is $14.94
About creating acceptance tests
• Ideally, the customer writes the acceptance
tests
• Acceptance tests are blackbox tests
– The test writer doesn’t get to read the tested code
• Tests should be unambiguous
About running acceptance tests
• Run acceptance tests at least once a week,
preferably more often.
• Often useful to have an integration machine
where you run acceptance tests.
– Representative of what the customer would have.
Pop quiz on unit tests
• Who writes the unit tests?
• Programmer
• When do the unit tests get written?
• Before writing the application code
Benefits of unit tests
• Clarifies the task at hand
• Frees you from writing perfect code
(temporarily)
• Makes reliable refactoring possible
About creating unit tests
• Unit tests start out as blackbox tests and
become whitebox tests
– They are 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
• So use representative testing instead
– Typical inputs
– Boundary cases
Writing the first test is the hardest.
• But keep in mind…
– “Your test suite is more valuable than your code”
– “If you want a good suite of tests next year you
must start collecting them today.”
Time to program
• You only code when the test suite is broken or
you are refactoring
• Your twin goals
– Pass the unit tests for today’s user stories
– Refactor to keep the bad smells under control
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.
Pair programming - benefits
• Real-time code reviews
• Copilot can help to catch implicit assumptions
• Pair programming takes 15% longer but leads
to 15% fewer bugs… a “win” for many projects
• Ideas and techniques spread throughout the
group
Pair programming – the driver
• The driver…
• controls keyboard and mouse
• is actively talking to the copilot
• explains intent of code and where s/he is going
Pair programming – the co-pilot
• Copilot is not a passenger! Copilots pay
attention, watch for mistakes, offer ideas
– Talk about and agree upon best course of action
– If you can’t agree, then take turns yielding to one
another’s preferences
• At any moment, copilot can request to switch
places and become the driver.
– Driver can say, “hold on a second” but should
switch as soon as possible
– You are working as a pair, a team.
Pair programming - principles
• If someone asks you to pair with him or her and
you can, then you must say yes.
• Code formatting: pick a standard as a team,
enforce it, and move on
• Font size and eyesight: choose a font large
enough for the copilot to see, too
• Take turns pairing with lots of different people
• If you write code alone, then it must be rewritten.
– If you have a brilliant idea when you’re alone, then
write it down.
Interacting with the team
• Periodically communicate your progress
– An end-of-day email is usually perfect
– Perhaps track progress with wiki or Google Wave?
• Use models judiciously
– Draw diagrams to help you reason
– Draw diagrams to communicate
– But only draw diagrams if it helps your team to get
the prey
In agile processes, models…
•
•
•
•
•
Must provide value
Must fulfill a purpose (and no more)
Must be understandable
Must be as simple as possible
Must be sufficiently
– accurate
– concise
– detailed
Not true about models in agile
•
•
•
•
•
•
•
•
•
Models equal documentation.
Modeling implies a heavyweight process.
Modeling freezes the requirements.
Models never change.
Models are complete.
Models must be created with a tool.
All developers know how to model properly.
Modeling is a waste of time.
The data model is the only one that matters.
Tips for agile modeling
• Don’t let the models distract from the hunt
• Model iteratively and incrementally
• Model with other people
– Involve stakeholders
– Own models collectively
– Display models publicly
• Create simple content
• Use the simplest tools
More tips for agile modeling
•
•
•
•
Don't spend time getting every line straight.
Follow standards
Reuse existing resources
Discard temporary models
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.
http://www.flickr.com/photos/orinrobertjohn/3598881393/sizes/s/
Continuous
improvement
http://www.flickr.com/photos/ajagendorf25/1076632419/sizes/l/
Bad smell: Long methods
• Sometimes you have a method that tries to do
lots of different things.
– Remember, code should have concerns!
– This applies to methods, too.
– Usually, >= 1 screen of code is too much.
• Most common way of refactoring:
1. Split the method into smaller methods.
2. Call each method.
Bad smell: duplicate code
• Sometimes you have a few lines of code that
appear in many different places
– Often happens during copy-and-paste coding!
– Usually, >= 3 duplicates are too many.
• Most common way of refactoring:
1. Create a new method (and/or new class)
2. Move the duplicated code into the new method
3. Call the new method from each old place
Bad smell: Large classes
• Sometimes you have a class that tries to do
too many things.
– Usually, >= 7 member variables and/or >= 50
methods is too many.
• Most common way of refactoring:
1. Pick the appropriate design pattern.
2. Break the class into pieces, using the pattern.
3. Fix up the code.
Bad smell: Long parameter lists
• Sometimes your method has a parameter list
as long as your arm.
– How is somebody supposed to remember what
parameters to pass into the method???
• Most common way of refactoring:
1. Organize some/all of the parameters together
into a hierarchy, using the composite pattern.
2. Pass an instance of the composite, rather than a
list of individual primitive values.
3. Consider moving methods into the class, too!
A few more refactorings
•
•
•
•
•
Rename
Delete unused method
Move
Introduce factory
Change signature….
(A step-by-step example in Eclipse.)
(Can be done manually… e.g., in PHP)
How to do a refactoring right
• You absolutely have to have a working unit
test suite.
– No refactoring allowed until you’re passing all
your unit tests
• Then, when you get a whiff of a bad smell, talk
with your pair programmer about it
• Try out the refactoring idea
• Run the unit test
• Iterate til you like the code & all unit tests pass
Refactoring early, refactor often
• If it takes you too long to refactor than you are
not refactoring enough.
– Many tiny refactorings are easier than a single
enormous refactorings.
– Each refactoring makes it easier to identify
opportunities for further refactorings.
Be alert for opportunities
• Refactor when…
– A new feature seems too difficult to code
– You just created a new feature, and the code will
be too hard for somebody else to understand
– You “can’t stand to look at your own code”
– You can’t stand to look at your teammate’s code!!
REMEMBER: It’s not your code, it’s your team’s.
Unit tests are your safety net
• “When the test suite stops working
(‘turns red’), it is unsafe to move forward.”
• “You might be driving, and then your copilot
gets an idea to refactor, so you switch and he
codes the changes, and then runs the test
suite and voila, it works.”
Shifting focus: improving yourself
• Focus so far: the code and the design
• Shifting focus to you: improving your team
Use the past to predict the future
• Once you have done a lot of software projects
– You (theoretically) can have a lot of data about the past
– Very little is completely new to you
• If the future is like the past, then you can use the past to
predict the future.
Key assumptions
• The future will be like the past
• You are reflective enough to pay attention to
yourself and what you’re doing.
– Not all people are so aware of themselves
• You are disciplined enough to take the time to
precisely record and use data
– And evaluate if your predictions are coming true
Example
• Joe & Ted are pair programmers
• They have implemented 4 web apps
Web app
Balloon sales site
Balloon rides site
Insurance sales site
Find-a-lawyer site
# application points
10
10
20
10
Months required
2
4
6
3
• How long should a 30 a.p. web app take?
Personal Software Process
• PSP is one way of collecting and using data
• Agile does not prescribe any particular
method for doing this
– But whatever method is selected, it should be
simple and not very time consuming
Tips for recording data
• Keep a notebook, spreadsheet, or other
software with you anytime you code
• Get in the habit of recording start/stop info
• Bugzilla
• If you forget to make a record, then write
down an estimate as soon as you remember
• At the end of the day, summarize data
– And send an email to your team if you’re falling
way far behind
Using the data
• For making estimates
– After you receive user stories from the customer,
and you’re dividing user stories into tasks, refer
to your data about similar tasks.
• For refining estimates
– Just before you release code to your customer,
and you’re talking with your team about how the
iteration went, refer to your data to refine
estimates of how long the next tasks will take.
Other opportunities for improving
your team
• At the end of an iteration, discuss…
– What interesting coding techniques did you
discover?
– What new IDE features did you find?
– What key problems did you encounter?
– Is one of your teammates really really good (or
bad) at something?
• Use this information for setting up future pairings.
Opportunities for improving
yourself
•
•
•
•
•
•
•
•
Online tutorials
Books
Mentors
User groups and other clubs
Conferences and workshops
Programming competitions
Volunteer gigs
Getting involved in research
Helpful online resources
• Web- and database-related stuff
– http://www.dynamicdrive.com/
– http://www.w3schools.com/
– http://dev.mysql.com/doc/
• Microsoft stuff
– http://msdn.microsoft.com/
Helpful books
• Design Patterns by Gamma et al.
• The Unified Modeling Language User Guide by
Booch et al.
• Problem Frames by Jackson
• Algorithms by Cormen et al.
• Contextual Inquiry by Beyer and Holtzblatt
What’s next?
• Thursday: consumer.
• Risk management : Another important concept
like scheduling. (waltzing with bears: I will be
reserving the book in the library). Each of you
will present a few chapters from the text book –
email each of you.
• Next Thursday: final project presentations
(should include scheduling and risk
management).
• No class during finals week