Transcript  KC Software Engineering Extreme Programming Test Driven Development  5-11-2015 Extreme Programming   Deliberate and disciplined approach to software development.  XP is successful because it stresses customer.


KC Software Engineering
Extreme Programming
Test Driven Development

5-11-2015
1
Extreme Programming

 Deliberate and disciplined approach to
software development.
 XP is successful because it stresses
customer satisfaction. The methodology is
designed to deliver the software your
customer needs when it is needed.
 This methodology also emphasizes team
work.
 XP emphasizes not just testing, but testing
well.
 XP enables us to embrace change.
 Early focus on risk issues.

5-11-2015
2
Extreme programming

 Verzameling ‘best practices’
 Communicatie
 Iteratief ontwikkelen
 4 onderdelen/fasen:




planning
designing
coding
testing

5-11-2015
3
Rules and Practices - Planning

 User stories are written.
 Release planning creates the schedule.
 Make frequent small releases.
 The Project Velocity is measured.
 The project is divided into iterations.
 Iteration planning starts each iteration.
 Move people around.
 A stand-up meeting starts each day.
 Fix XP when it breaks.

5-11-2015
4
Rules and Practices - Designing

 Simplicity
 Use CRC (Class, Responsibilities, and
Collaboration) cards for design sessions.
 Create spike solutions to reduce risk.
 No functionality is added early.
 Refactor whenever and wherever possible.
 Choose a system metaphor, presenting a
common vision
 Bijvoorbeeld: At a auto manufacturer car sales
were structured as a bill of materials.

5-11-2015
5
Rules and Practices - Coding

 Make it work, make it right, then make it fast.
 The customer is always available.
 Standards
 Write the unit test first
 Pair programming
 Integrate often
 Single threaded integration
 Collective code ownership

5-11-2015
6
Rules and Practices - Testing

 All code must have unit tests.
 All code must pass all unit tests before it can
be released.
 When a bug is found tests are created.
 Acceptance tests are run often and the score
is published.

5-11-2015
7


5-11-2015
8


5-11-2015
9
Extreme Programming – How to start

 When starting a new project
 User stories en spike solutions
 Iteration planning (together: customers, developers,
managers)
 When in trouble:
 Identify the (main) problem and focus on that problem
•
•
•

5-11-2015
For example, if you find that 25% of the way through your
development process your requirements specification
becomes completely useless, then get together with your
customers and write user stories instead.
If your biggest problem is integration bugs then try automated
unit tests. Require all unit tests to pass (100%) before any
new code is released into the code repository.
If one or two developers have become bottlenecks because
they own the core classes in the system and must make all
the changes, then try collective code ownership. (You will also
need unit tests.) Let everyone make changes to the core
classes whenever they need to.
10
Test Driven Development

 It’s about unit testing
 Write test code first, before functional code
 Small steps
 Unit test framework is essential
 In case of an error outside testing
 First: Write a failing unit test
 Then: Fix the code

5-11-2015
11
TDD voorbeeld


5-11-2015
12
Referenties

XP
http://www.extremeprogramming.org/index.html
http://www.xprogramming.com/
TDD
http://www.testdriven.com

5-11-2015
13