Lesson 7: Extreme Programming (XP) & Test-Driven Development (TDD)
Extreme Programming (XP) is one of the best-known and most complete agile methods, created by Kent Beck in 1996 — even before the term 'Agile' was coined. In this lesson we meet XP's four core values (Simplicity, Communication, Feedback, and Courage), the 12 practices (in Beck's original formulation
In brief: XP says 'take the good things we do and amplify them' — communication, simplicity, feedback, and courage. And TDD says: first write a test that fails, then write just enough code to make it pass — and then stop.
- Extreme Programming (XP)
- An agile development method created by Kent Beck in 1996, among the most complete and best-known; built on four values (Simplicity, Communication, Feedback, Courage) and 12 engineering practices, on the idea 'take what works and amplify it'.
- Test-Driven Development (TDD)
- A method where you first write a unit test that must run and fail, then write code until the test passes, and stop the moment it passes — without adding functionality; no previously-passing test may fail.
- Planning Game
- An XP planning practice that separates business from developer decisions: the business presents and prioritizes user stories, developers estimate effort, and iterations are short (1-2 weeks) and never exceed their allotted time.
- User Story
- A short card (name + description) of a feature that brings value to the customer, written by the customer and estimated by developers; replaces large requirements documents, similar in purpose to a use case.
- Pair Programming
- All code is written in pairs at one station: one writes, the other thinks about whether it will work, better ways, and test scenarios; they swap roughly every two hours and pairs rotate — supporting collective ownership and informal review.
- Refactoring
- Improving the structure of existing code without changing its behavior, to keep the design simple; an ongoing, not one-time, activity in which the tests guarantee behavior did not break.
- Continuous Integration (CI)
- Building and testing the whole system several times a day (integrating at least daily), with automated tests; unit tests must pass 100% before and after integration.
- Sustainable Pace (40-hour week)
- 'Coding is a marathon, not a sprint': the team works up to 40 hours a week; tired people are not productive; in a crisis up to one week of overtime is allowed, but consecutive weeks signal something is wrong.
