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) and the 12 practices in Beck's original formulati
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.