Transcript cs.hiram.edu

XP Programmer Practices
Introduction to TDD
November 3, 2006
Matthew Snyder
Progressive, Direct IT
Agile Manifesto
We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
●
●
●
●
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
Programmer Practices
●
●
●
●
●
●
●
Test-Driven Development (TDD)
Refactoring
Simple Evolutionary Design
Continuous Integration
Collective Ownership
Pair Programming
Single Coding Standard
Simple Evolutionary Design
●
●
●
●
YAGNI (You Aren’t Gonna Need It)
Fewer lines of code = fewer defects
Extensible
Refactor Refactor Refactor!
Refactoring
●
●
●
●
●
●
Removes duplication; Rule of 3
Clarification and simplification
Eliminating code smells
Improving the design of working code
Behavior-preserving structural changes
Don't reinvent the wheel, use the patterns
–
Code-smells are named, refactorings are named
Refactoring - Code Smells
●
●
●
Investigate the smell
May not smell at all
Might have to be tolerated
Ex. Long Parameter List
–
void DoSomeStuff(obj1, obj2, obj3, obj4 ... obj10);
–
How many is too many?
Refactor to Parameter Object
Single Responsibility Principle
Recognize it and tolerate it
–
–
–
More Code Smells
●
Comments
–
–
●
Dead Code
–
●
.add(course) instead of .addCourse(course)
Primitive Obsession
–
●
Say goodbye and delete it!
Type Embedded in Name
–
●
Should clarify “why”, not “what”
Use Rename Method, Naming Variable, Extract Method
Use small objects to represent data
Speculative Generality
–
–
Don't over generalize your code!
Collapse Hierarchy, Rename Method, Remove Parameter
Continuous Integration
●
●
●
●
●
●
Frequent commits, short cycles
Integrate new code immediately
Never leave for the day with code not checked in
Throw away code
Automated unit tests
Deployable code base
Collective Ownership
●
●
●
●
●
Everybody shares all the code
No Cowboys or White Knights
Anybody can change any code
Everybody knows all the code
Design consistency; Coding standards.
Pair Programming
●
Increased truck number
–
–
●
●
●
●
Spreads design/architecture knowledge
Spreads code & test knowledge
Spreads technology knowledge
Spreads programming craftsmanship
Slower than solo work ... only by 16%
Not for everyone
Pair Programming (cont.)
●
●
●
●
●
●
●
●
Builds cohesive teams
Integrate new members
Slow up the experts
Speed up the novices
Let the chatty learn to listen to the shy
Let the shy learn to speak up a tad
Let the arrogant be humbled
Let knowledge spread
Single Coding Standard
●
I don’t care where you want to put the curly braces
–
●
●
●
●
●
Just always put them in the same place
Industry standard
Program with Intention!
Use automated formatting tools
Refactor/test-drive to your standard
Unidentifiable author
Program by Intention
●
●
●
●
●
The code explains what it does
Choose good names, rename as needed
Don’t look too far ahead
Wait until the last possible moment
Comment only unusual code:
–
–
“Don’t refactor! Performance tweak.”
Comments are a code smell
Test-Driven Development (TDD)
Why TDD?
Increased
● Quality
● Robustness
● Clarity
● Maintainability
● Flexibility
● Predictability
● Fun
Decreased
● Defect rate
● Learning curve
● Programmer burnout
● Maintenance cost
● Release cycle time
● Complexity
What is TDD?
●
●
●
Testing to the eXtreme!
Unit Tests (Programmer Tests)
Tests define what it means for the code to work
–
●
●
●
●
●
TDD is a design exercise
No production code exists unless a test requires it
Test is written first
Prove the code works
By definition all code is tested
TDD covers XP's arse!
What to test?
Use your right-BICEP
●
●
●
●
●
●
Right – Are the results right?
B – Boundary conditions
I – Inverse relationships
C – Cross-check
E – Error conditions
P – Performance characteristics
Test Cycle
●
●
●
Write a test that specifies the behavior you want
Watch the test fail; prove your test works
Do the cheesiest thing
–
●
●
Watch the test pass
Refactor!
–
–
●
●
Write simple code to let the test pass
Use the Rule of 3
Watch the test pass
Test/code cycle is 5 - 10 minutes
No new tests until all existing tests are passing
References
Extreme Programming Explained: Embrace Change
by Kent Beck and Cynthia Andres
Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Test Driven Development: A Practical Guide
by David Astels
Pragmatic Unit Testing in C# with Nunit
by Andy Hunt and Dave Thomas